A second review -- an independent reimplementation of welch_t / pooled_percentile / t_values /
crop_statistic that reproduces report.json exactly -- found seven defects in revision 1. Every
number below was re-verified locally before acting on it. The design survives; three of my claims
do not.

WITHDRAWN: "10.24 / 1.742 = 5.88, within 1% of the boundary". That number should never have been
computed. It divides a max-of-nine ORDER STATISTIC by an sd measured on the RAW t: the nine crop
t's have their own spreads across the 20 null sessions -- 3.82, 4.79, 5.21, 5.63, 4.69, 3.94,
3.24, 2.91, 2.33 -- and none of them is 1.742. The max is attained at crop 0.80 in 8 of 20
sessions and at six other crops in the rest, so it is not even a fixed statistic. Cropping also
shrinks the denominator (SE 2466 ns raw vs 906 ns at crop 0.50 on raw-sign-rr.csv), so removing a
location offset deflates the crop by MORE than the raw factor -- the opposite direction to what
"the same factor" assumed. And every stable-looking estimate disagrees: the chi-square band maps
10.24 to 4.03-7.73, spanning all three outcome branches; two decompositions give 4.97 and 7.31.

OVERSTATED IN ITS OWN CONSEQUENCE: "v3.1's PASS may flip". Revision 1 named only the middle
outcome -- the one that does NOT change the verdict. All three are now pre-registered, with
thresholds read off the code (SHAPE iff the crop exceeds ALL 20 null sessions; sign-kk combines at
>= 2 of 3; session = worst of kk_combined and sign-rr; the three kk crops are 3.4754 / 5.3584 /
5.8405):
  >= 5.8405           nothing moves                      -> PASS unchanged
  5.3584 - 5.8405     sign-kk-1 alone SHAPE              -> PASS UNCHANGED (one pair cannot carry
                                                            >=2-of-3); one CT_REPORT row and one
                                                            sentence need correcting
  < 5.3584            kk-1 AND kk-2 SHAPE                -> session SHAPE
Flipping the SESSION needs the v4 null's crop max below 5.3584, not below 5.84.

AND THE BEST AVAILABLE PRIOR SAYS IT DOES NOT FLIP: v3b's 20 null sessions carry an inflation of
only 1.004-1.024, so they are ALREADY a v4-equivalent null on the location statistic. Their crop
max is 5.749 -- between kk-2's 5.358 and kk-1's 5.840, i.e. the middle branch. n = 2352 against
v3.1's 40180, so it settles nothing, but it is evidence and it belongs in the file.

FALSE AND WITHDRAWN: "every 'no SHAPE' reading in v2, v3, v3b and v3.1 was made against an
inflated null". Checked against the committed reports: v2's null was 24 FLAT-LOOP sessions -- a
NARROW null -- and v2 returned SHAPE on all six signing experiments, so it contains no "no SHAPE"
readings at all; v3's first run had null_ok:false and minted nothing; v3b's inflation was under
2.5% and immaterial. ONLY v3.1 had a materially inflated null. Over-claiming about this project's
own record is the exact failure this file exists to correct, and I did it.

ALSO FIXED:
- The contradiction between 2a and 3.3 over which reference judges sign-kk. Named: repeated
  sign-aa. Ambiguity resolved BEFORE any measurement.
- "All ten experiments' raw samples are committed" -> report.json holds 9 experiments, the
  directory holds 11 raw CSVs, SHA256SUMS covers 13. And the null side is NOT recoverable, so a
  re-judge compares August's experiment crops against a null measured later, on different key
  material, in a different thermal state. Stated.
- The design was never priced. Measured: mean sign is 7.7066 ms, one 82k block is 632 s, 20 null
  sessions are 3.51 h = 63.6% of v3.1. Three references at 82k is ~10.5 h of null before an
  experiment runs. So v4 session 1 is a VALIDATION run at v3b scale (~1 h) whose only job is to
  answer whether null-ss gives sd(t) ~ 1; sizing a verdict session comes after. Running a 10-hour
  verdict session on an unvalidated null would repeat the v3.1 ordering mistake at five times the
  cost.

NEW 2b, alternatives rejected -- including one that would have been a disaster: a
label-permutation surrogate null returns sd(t) ~ 1 BY ALGEBRAIC IDENTITY whatever the data holds.
Run on raw-control-leaky.csv, whose raw t is -296.34, it returns 0.97. A reference that certifies
the deliberately leaky control is the check-that-cannot-fail defect this repo keeps a register
for. Excellent regression fixture, not a null.

AND a second confirmation of the defect that never touches a t statistic: sd(dmean) = 3229.8 ns
against rms(se) = 1839.1 ns implies a between-pool offset sd of 2655 ns, hence a predicted sd(t)
of 1.756 against 1.742 observed; both routes put sigma_key at 10.49 / 10.62 us.

Still a DRAFT, in force nowhere.

Security Impact: none - a design document. No code, no vendored C, no flags, no rule in force.