e89365295b
+1 body (0x800C1424, worker C claim 18, closed with two register-allocation levers: guard-on-the-expression so CSE keeps one load whose destination is the guard's operand, and a counter initialisation as a statement so the counter takes a2). FORECAST FINDING (the important part of this commit): measured the matched corpus against the remaining pool and re-ranked the lever files. matched: 459 regions, median 48 bytes, 454 of 459 at <=200 bytes remaining levered rows: median 456 bytes Size is therefore the strongest predictor left, so .run/p10/lever*.tsv now ranks size band FIRST and lever second: P1 = <=200B and levered (47 rows across partitions) P2 = <=200B, no lever (412) <- the unexploited band that actually matches P3 = levered but >200B (503) P4 = rest (303) Worker C had proposed continuing on fresh P1 rows (old meaning: known-callee), which under the new ranking are mostly P3 -- the 200-800B band where the allocator/optimiser tie-breaks live. Redirected to P2 from the top. Worker C's measured re-flag accepted (last 12 attempts produced 1 match, 8 of 9 sub-8-byte negatives being cc1 scheduling/allocation with no spelling lever) and answered with a band change rather than a stop, since C is at 47% context.