Enrol the five host_capacity wet route gaps so the nominal floor holds them instead of blocking

[gunbai-bot]

#11962 landed dag/test/claim/compute/host_capacity_wet_witness_test.dag with TWO of the three
rows the mechanism requires, and nothing refuses an incomplete triple. The consequence is the
merge queue refusing PR #11829.

What the floor actually did

Queue run 35673852146 (composed revision on 3ab9d31), job floor:

required-floor: planned=432 executed=432 ... route_gap_unenrolled=5 route_gap_held=7
required-ci: adjudication REFUSED standing=measurement_completed blockers=5

Twelve identities NO-ROUTEd in that run. Seven were enrolled in v2.workflow.floor_route_gap
and therefore HELD; five — all in this module — were not, and blocked. This change enrols
exactly those five.

The brief's diagnosis is ruled out by the receipt

The module did not reach the nominal plan through the gate prefixes, so no exclusion could have
removed it: the same run reports disposition=planned_as_changed_witness. The changed-witness
sublane admits a changed witness REGARDLESS of any exclusion
(cause=ChangedWitnessOutsidePreparedSubject), deliberately, so that an exclusion list cannot
be how a witness opts out of the commit that introduces it. Independently,
floor_prepared_subject_exclusions in v1_compiler.cli_run is the list run_required_floor
consults, and it is a separate roster from witness_exclusion_frontier. "The nominal lane must
not plan what only the wet lane can run" is therefore not available for a witness whose file
the PR edits; enrolment is.

This is not adjudicator tolerance

HostEffectRefused names three remedies and this takes the third: supply a lane that can run
the effect. The lane is already supplied and already ran — the same job records all seven
identities of this module expected=passed observed=passed on the local-repo wet lane, and the
changed-witness projection already reads standing=hermetic-route-gap-held-and-wet-passed for
exactly these five. The hold is discharged by that wet terminal, never by the enrolment; the
enrolment only stops a measured, routed-elsewhere identity being counted as unmeasured. No wet
claim is deleted and no expectation is weakened.

Operation DirWithTemplate and ground NoMockResponse are READ from the run's refusal text,
not copied from the neighbouring Dir chunks — a wrong operation produces
floor_route_gap_expectation_mismatch, not a discharge. The module's other two identities reach
their subjects hermetically and are deliberately absent, since enrolling them would be a
stale_route_gap.

EVIDENCE, AND THE CONTROL THIS PR STRUCTURALLY CANNOT PRODUCE

No head of this PR can prove the discharge, and no future head can either. Stated up front so
the next reader does not go hunting for a control that cannot exist here.

The route gaps arise ONLY in the changed-witness sublane, so they appear only on a revision that
edits dag/test/claim/compute/host_capacity_wet_witness_test.dag itself. A PR that merely edits
the roster does not select that witness, and no required_gate_prefixes row admits it. So this
PR's own floor runs green over a population that EXCLUDES the five identities it enrols.

The two runs that bracket the fact, both on revisions other than this PR's:

run	revision	what it shows
35673852146	queue, pr-11829 on 3ab9d31	the five PLANNED and UNENROLLED: route_gap_unenrolled=5 route_gap_held=7, adjudication REFUSED standing=measurement_completed blockers=5
35677754360	queue, pr-11931 on f5bd9b0 (post-merge)	an UNRELATED revision passes clean: adjudication PASSED standing=measurement_completed blockers=0, route_gap_unenrolled=0 — because it does not touch that witness, so the five are never planned

The second run is NOT evidence that this change works. It is evidence of why the first one is the
only shape of control that bites: the same tree, with and without an edit to that witness file.

What this PR's own CI DOES establish, on run 35679410107: the rows parse and resolve (compiler
pass), chunk_21 is consumed (it is wired into floor_route_gap_expectation_chunks), and nothing
is over-enrolled (stale_route_gap=0 — which is what would fire had I enrolled the two identities
that reach their subjects hermetically). The wet lane still runs all seven
([local-repo-wet] expected=passed observed=passed).

A failed attempt to force the condition, recorded rather than dropped. Commit ddc013de60f
was pushed partly to put the module back in the changed set. It does not: the edit is
annotation-only, and annotations are erased from the semantic projection before the touched-entry
seed runs. That run reports phase=touched-entry-compile-subject seeds=1 modules=["v2.workflow.floor_route_gap"]. The commit's second stated reason is therefore FALSE.
Its first reason — naming the three carriers on the file that needs them — stands on its own, and
is why the commit is kept rather than reverted.

Status note: #11829 merged directly at 2026-09-22T01:58Z (f5bd9b064ad), so this PR is not
blocking it and is not blocking anything. It stands on its own as the repair for an incomplete
enrolment triple.

Known and not closed here

floor_route_gap_expectation_chunk_06's header already states that the three-authority coupling
is enforced by nothing and that this exact failure will recur. It has now recurred a third time.
The wall it asks for is a separate change.

🤖 Generated with Claude Code