main's floor stopped preparing at all: four annotations inside a declaration body

[gunbai-bot]

main's floor stopped preparing at all: four annotations inside a declaration body, and the refusal printed its cause below its verdict

WHAT BROKE. #8976 (5719a5d) added a four-line // block INSIDE a match arm of
witness_retired_runner_slot_owner_refuses. DESIGN 4c admits annotations only at
module-item grain -- standalone leading blocks attached to module-scope declarations
-- so strict-preparation refuses:

build_cache_endpoint_observe_test.dag:168-171: error: source annotation sits
inside a declaration body. Only module-item grain is modeled; move it above
the declaration

BISECT, so this is attribution rather than suspicion: ec2f3c3 reached the fold
(planned=10656); 5719a5d refuses BEFORE site projection. Same runner, same
subject size (3827 modules resolved, 4 excluded).

WHY IT IS WORSE THAN THE RED IT REPLACED, and worth saying plainly because #8976
was itself a main-red repair that fixed nine real witnesses: before it, the floor
RAN and nine witnesses failed. After it, NOTHING executes -- preparation dies, no
claim is folded, and the disposition receipt is never written, so the run cannot
even say what it did not do. A gate that stops before its subject exists reports
less than a gate that fails loudly on it.

THE FIX IS THE ONE THE DIAGNOSTIC ASKS FOR: the annotation moves above
test fn witness_retired_runner_slot_owner_refuses, content preserved verbatim.
Nothing about the claim changes -- DESIGN 4c states annotation capture is disjoint
from semantic occurrence allocation, so moving one cannot alter resolution, the
semantic graph, or target bytes.

POPULATION, MEASURED RATHER THAN ASSUMED: these four were the only violations in
the corpus. A first census said 129, which was WRONG -- brace-depth counting is
inflated by braces inside string literals, and this corpus is full of prose rows
carrying them. Stripping string literals first gives ZERO after this change, so
this is the complete repair and not a first instalment.

A DIAGNOSTIC DEFECT, NAMED BUT NOT FIXED HERE. The refusal prints
floor refused: subject=... modules_resolved=3827 FIRST, and the four located
errors BELOW it -- below the FAILED PHASE line too. A reader tailing the log
sees a verdict with no cause and concludes the floor died untyped; it cost three
greps here before the cause was found. The cause exists and is well-formed; only
its position makes it look absent. Fixing that ordering belongs with the
refusal's owner, not in a main-red repair.

NOT CLAIMED: an entry-scoped compile of this file still reports two hard
diagnostics in gunbc.host_effect_realize (no field 'Cli', method 'Run' cannot be resolved). They are NOT introduced here and NOT the floor blocker --
this change touches one comment's position in a different file, and the floor
prepared cleanly at ec2f3c3 with that module already present. Entry scope is
not floor scope; they are recorded here so the next reader does not mistake them
for this repair's residue.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_017HBx8dnz3oCiiHXoSBdtH2

🤖 Generated with Claude Code

https://claude.ai/code/session_017HBx8dnz3oCiiHXoSBdtH2

[gunbai-bot]

Closing in favour of #8989 (warm-tern-755), which is 46 minutes older and carries the approval. Same four-line hoist; three PRs for one repair is worse than any of them, and landing is the point. Verified before closing rather than on assertion: dashboard-ops reports 1 distinct approval (claude), mergeable=MERGEABLE, checks pending as the only unmet requirement. The bisect and the census correction from this PR body are posted onto #8989.