docs(perf): land the four corrections PR #52's squash dropped

[akutuva21]

Follow-up to #52, which merged carrying only one of five corrections.
Documentation only — one file, no production code.

What happened

PR #52 squash-merged as a16f460 with only the +0.024% correction. The other
four commits were pushed after the merge and never landed. Verified before
acting rather than assumed:

git show origin/main:docs/PERF_EXPRESSION_CODEGEN_NO_WIN.md | grep -c "<each phrase>"
-> determinism precondition: 0     (absent)
-> Scope of these two hashes: 0    (absent)
-> Scope of that gate: 0           (absent)
-> prescription that has since gone stale: 0  (absent)

The correction I had pushed first was the only one in the merge. This is the
same shape as every other error in my charge: a stale reference treated as
current. I verified the push succeeded and never verified the merge contained it.

What lands here

1. Determinism precondition, shown rather than implied. A hash guard is only
   evidence if the artifact is deterministic. Measured, not argued: same binary,
   two runs, 4,000,002 rows each, identical sha256 a27182ec…d05b. The fixture
   is a fixed-step ODE with no RNG, but "by construction" is an argument and the
   two-run check is a measurement.

2. Both artifact surfaces are hashed — .gdat and .net. This one is
   load-bearing and I had only shown the .gdat command. An instrument's
   sensitivity must be a superset of the defect class it is meant to detect.
   A .gdat-only gate is blind to network-generation nondeterminism entirely:
   correctness's P0 (44664f1) perturbed .net bytes without necessarily
   perturbing trajectory values. I had run the .net hash and quoted it in
   passing without saying why both surfaces mattered.

3. Hash scope pinned to the commit that produced them. Both came from
   binaries at 8dd441d. They are evidence internal to that one comparison, are
   not expected to reproduce on main now that the determinism fix has landed,
   and a reader who tries and gets a different value must not read that as
   evidence against this document. Stated in the same shape swarmCache named:
   a count from a pre-fix binary and a post-fix binary mean opposite things, and
   the output alone cannot tell you which you are looking at.

4. The ctest gate scoped to its commit. 461/461 was produced at 6889fba,
   which does not contain the duplicated test_correctness_regressions block
   (grep -c → 0). At the time, origin/main did not configure at all — now
   fixed in 3409bc2. So the 461/461 is a real result for that commit and is
   not evidence that main configures. The generalisable part: an incremental
   cmake --build cannot see that class of failure, because every existing
   build.ninja predates the duplicate — the stale instrument here was the build
   system itself.

The no-win verdict does not depend on any of the above. It rests on the profile
(zero frames in four end-to-end runs) and the 4.89% ceiling measurement, neither
of which requires a fresh configure. The gates were corroboration, never the
basis.

Verification of this PR's own scope

git diff --name-status origin/main HEAD
-> M	docs/PERF_EXPRESSION_CODEGEN_NO_WIN.md
52 insertions, one file, no production code.

Recovered by restoring the single file from 5f36268 onto current main
rather than rebasing that tip — the tip predates several merges and would have
dragged in six unrelated files from other lanes. That is the third time this
branch family drifted against a moving main; the fix each time was to compute
the diff against a freshly fetched base rather than a remembered one.

🤖 Generated with Claude Code

[akutuva21]

Closing per maintainer request to prune the queue and focus on the remaining PRs. The branch was rebased onto current main at fb97480 if the corrections are ever needed again.