docs(perf): correct the +0.024% figure published in #38

[akutuva21]

Follow-up correction to #38, which merged before this landed. The document
on main currently states B = +0.024% as a resolved delta. It is not
resolvable. This PR corrects it. Documentation only, no production code.

What is wrong on main

#38 merged at 25da219, before I found the error. The merged document reports
the instruction counter as settling the question at +0.024%, i.e. the
candidate slower, phrased as though the counter had resolved a difference.

It had not. Re-analysing the two independent datasets I collected:

instr.txt    A_med 5,039,373,445  B_med 5,037,690,571   -0.033%  -> B FASTER
instr2.txt   A_med 5,037,345,446  B_med 5,038,543,790   +0.024%  -> B SLOWER

The sign flips between datasets, and the between-arm delta (~0.03%) is
smaller than the within-arm full range (0.061%–0.099% of median). The honest
reading is no measurable difference in either direction.

Same class of error as the original retracted 23.6% claim, one order of
magnitude smaller. It survived because I trusted my own counter's label instead
of measuring its spread — the check swarmMemory applied to its own allocation
counters after finding a 13.69% full range under a "deterministic, min==max"
label. Mine had a 0.06–0.10% range and I still quoted 0.024% against it.

What this PR changes

• The instrument section no longer claims the counter resolved a delta. It
  states what actually mattered: the counter contradicted wall clock's
  +4.78%, and that contradiction is what killed the candidate.
• The population table row for candidate B reads flat — sign flips between
  datasets, delta below within-arm noise, replacing the false precision.
• The rule is now explicit: compare the between-arm delta against the
  within-arm range of each arm before quoting any delta. Tightness does not
  license it — a tight-looking counter makes you more confident, not less, which
  is exactly when the check gets skipped.
• The counter's resolution limit is stated: a ~0.1% floor means it can
  adjudicate a 23.6% claim, not a 0.03% one.

Second correction in this PR: the writeOutputFiles pointer is stale advice

The document also told the next operator that writeOutputFiles is "where a
codegen-shaped win would actually land on this platform". That is now actively
misleading rather than merely unhelpful:

1. cpp/engine/OdeIntegrator.cpp now carries seven declared lanes —
   writeOutputFiles, updateFunctions/derivs, integrateSSA,
   computePropensity, compile, compileGroups, and the batch-SSA seed
   derivation. Seven touching hunks in one file is the shape that silently
   reverts a fix when someone resolves a conflict by picking a side. The
   finding — where the time is — is durable; the location is now a poor place
   to aim.
2. The win that landed there was not the shape I predicted.
   swarmSerial measured 2.75x there (0.11s → 0.04s, byte-identity held across
   30 artifacts), which vindicates the hotspot measurement — but it arrived as a
   formatting change. I inferred the kind of fix from the location of the cost
   without checking, which is the same error class as the rest of this file:
   evidence about where time was spent, dressed up as evidence about what would
   remove it.

The transferable form, now stated in the document: a profile tells you where,
and nothing about what kind of change will help there.

This also removes a second surviving "deterministic counter" claim in the
instrument-limitations list that the +0.024% correction superseded elsewhere
in the file but missed here.

The verdict is unchanged, and slightly better supported

The no-win stands. The candidate does not merely fail to win; it is
indistinguishable from baseline in a metric tight enough to have caught a real
difference. That is a stronger claim than "+0.024% slower", and it is the one I
would rather have defended.

Files: docs/PERF_EXPRESSION_CODEGEN_NO_WIN.md only. No production code.

🤖 Generated with Claude Code