Extract run_stage so both walk populations share one executor

[briansrls]

Task #13, following #7470 and #7481. Extracts one stage executor for both walk populations, retains the full parsed resource profile that makes stage contracts enforceable, and closes receipt identity before the admission occupants become its first consumer.

This body was rewritten after review. An earlier version asserted several things that turned out to be false, and one of them caused a wrong code change. Those are corrected below rather than quietly dropped, because the false version is what made the wrong change look justified.

---

The prerequisite

Runnable::SingleClaim retained two of the four facts RunnableResourceProfile declares — heavy_whole_tree_resolve (as use_walk_memo) and execution_mode — and dropped spawns_host_compiler and the memory class at parse time.

That was invisible while only the ordinary batch path consumed profiles, because that path happens to need exactly the two that survived. It stops being invisible the moment one executor serves both populations: a shared run_stage cannot enforce a stage's declared resource contract against facts the parse threw away.

ParsedRunnableProfile retains all four. Two distinct absences now refuse rather than default:

• a profile that exists but omits an axis → refusal (the node_frontier_selection precedent — a stale plan redeclares rather than inheriting silently)
• no profile at all → ParsedProfileProvenance::Undeclared, and stages refuse it, because the values would be the parse's fail-closed fillers rather than the plan's statements, and reading a wall off invented facts is worse than having no wall

The extraction

Both populations run through run_stage: same unit grouping, same lane partition (batch_unit_lane), same derived cost clamp. The callers differ only in ordering and failure policy — FloorBatchStopPolicy for the ordinary floor, unconditional fail-fast between stages.

Admission is per-lane, not universal, and stating that precisely is the load-bearing correction. run_batch_unit takes an AdmittedSlot, and run_batch_unit is reached on the spawned lane only. Memo-lane and main-thread units run unadmitted. There is exactly one acquire_blocking site in the file.

The wall that was wrongly removed, and is restored

An earlier revision deleted the arm-time heavy-whole-tree-resolve refusal, arguing that stages now took the same lane partition as batches so a heavy claim was governed exactly as it would be in a batch.

The partition is shared; the admission is not. batch_unit_lane routes a heavy unit — and every unit sharing its entry — to UnitLane::Memo, which runs through run_memo_shared_claims, which takes no governor and acquires no slot. So a heavy stage claim would have resolved and evaluated on the main thread, unadmitted, while spawned units held slots: precisely the unbounded stacking the governor exists to prevent. The refusal is restored with that as its stated reason.

Wrapping the memo call in an ordinary slot is not the fix either — the slot would release while the resolved InterpContext stays resident in stage_memo for every later stage.

And the obvious repair — hold a slot for the memoized context's lifetime — deadlocks, which a later probe against decide_admission established. AdmittedSlot is a concurrency slot, not a memory reservation: a resident hold pins active >= 1, so the active == 0 progress floor never fires and every later admission returns Hold(WindowFull); width grows only in note_completion, which needs a completion, which needs an admission. The runner starts at target_width=1, so this is the default path, not a corner case. The real dissolve-on is splitting the governor's active counter into an execution slot and a resident memory reservation — its own work, on the path guarding against the exit-137 OOM kills, not a step inside this lane.

What the carrier now promises

The concurrency contract on walk_plan_note was weakened, because the executor can legitimately withdraw overlap without anything being wrong: same-entry same-mode claims are combined into one resolve group and run serially within it; memo-lane and discovery units run on the main thread; and at governor width 1 two spawned threads exist while one claim body is admitted at a time. Promising wall-time concurrency would make grouping, memo placement, and the governor into contract violations when they are the design.

What the admission occupants actually need is the absence of a guaranteed order, and that is what the type now states.

Receipt identity

On-success stage receipts were written to a bare shared path with no attempt identity. The occupants land next as their first consumer, so identity closes now — before there is a reader to fool. Per merge_admission_attempt_scope_note:

• identity is stamped in the payload, not just the path, because a misrouted read must fail on the content too (path scoping is added as hygiene against workspace reuse on self-hosted runners, but the payload stamp is the wall)
• an unidentified walk refuses rather than defaulting — a silent constant would make every local run one attempt and put the wrong-attempt refusal out of reach off CI
• the refusal fires at arm time, so an unidentified walk fails in seconds rather than after a 20–30 minute floor
• identity is demanded only when stages exist; a plan with no stages writes no attempt-scoped receipt, so requiring it there would be a refusal with no subject

GUNBC_WALK_ATTEMPT_ID is not an escape hatch: it supplies a required input the environment did not, and a value failing the segment law still refuses.

Controls, and the mutations that prove they discriminate

The concurrency contract was unreachable by a test while spawn-and-join sat inlined in the batch loop — which is how the first attempt at success stages promised concurrency while executing serially. spawn_units / join_units are split out so a latch can reach them.

control	mutation	result
stage_members_actually_overlap	spawn_units runs each unit inline	RED, serial signature [false, true]; join + panic controls stay green
attempt_identity_refuses_rather_than_defaulting_when_absent	absent identity defaults to "local"	RED, together with the partial-triple control; the three positive controls stay green

The bounded wait in the overlap control is a deadlock detector, never the assertion — the assertion is that each member saw the other, which slowness cannot fake and speed cannot satisfy serially.

The stage barrier is the join half plus a structural fact: run_walk's stage loop takes &mut stage_memo per iteration, so two iterations cannot overlap.

Verification

• 48/48 executor suite
• Both mutations above run and reverted; controls re-verified green after revert
• Full CI green on the prior head (032bd81e6): build, heal, regen, ci floor
• cargo fmt --all --check clean

Near-misses worth recording

The first fixture run reported exit 0 with no output through a grep, so a .dag parse error I had just introduced looked like a pass. An exit code is not a receipt when the filter can hide the diagnostic.

Separately, a walk_plan_note edit landed without regenerating the stage0 seed, redding regen. Both are why later commits here were held rather than pushed on green.

Not here

The admission occupants (capture_tested_subject, stamp_tested_floor, refresh_target_and_gate) go in their own PR. They do not exist yet — the pure classification half does, but the effectful half is new surface (git observation, receipt writes, gate refresh) and deserves its own before/after receipt.

They also need ci_floor_declared_resolve_count raised, which must land in the same commit that adds the escaping entry (declared > measured reds immediately). The operator has signed option A — pay the declared cold resolve rather than build the governor lease — and the exact delta will be measured before the number moves, since the carried "1→2" is analysis, not measurement.

Two further review items are dispatched separately: a production-path WalkPlan fixture, and a success-stage materialization receipt.

🤖 Generated with Claude Code

https://claude.ai/code/session_01N7LfCpidMuDjV3FxYUHv1K

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.