main red: roster the #7269 witness blob (declared 27 vs rostered 26) — #7269/#7272 merge race

[briansrls]

Summary

main is red; this is the one-row fix. compiler_tests_rust_blobs_are_all_rostered
(dag/test/claim/language_source_scaffold_index_test.dag) returns Bool(false) on main,
failing gunbc_ci_floor_batches batch 3 and blocking every merge in the tree.

The witness compares declared blobs against rostered rows for the
v1.compiler.compiler_tests_rust carrier:

side	source	count
declared	src/v1/compiler_tests_rust.dag, fn ct_ prefix	27
rostered	language_source_scaffold_roster, carrier v1.compiler.compiler_tests_rust	26

The single unrostered blob is ct_render_rust_applied_type_qualified_base_test.

Root cause — a merge race, not a defect in either PR

• Gate-1: render_rust_applied_type dotted-base leaf routing #7269 (merged 12:53) added the ct_render_rust_applied_type_qualified_base_test blob — the
  discriminating witness for dotted-base applied-type rendering. No roster row was possible: the
  roster did not exist yet.
• Language-files cleanout: derive operator emission from typed rows + typed scaffold inventory #7272 (merged 12:58) introduced the typed scaffold inventory and this witness, built
  against a tree snapshot that predated Gate-1: render_rust_applied_type dotted-base leaf routing #7269. Its roster was complete for the tree it was
  written against.

Neither branch was wrong on its own. The collision exists only on main, and it surfaced on the
first post-merge run — the unconditional main-push cold control catching what affected-set
scoped per-PR runs structurally cannot. That is the documented one-merge acceptance window
working as designed, not a skipped gate.

Failure is reproducible and not flake: gh run list --branch main shows failure at
0236b5048a (#7272) and failure at 862bb773df (#7268), with every preceding run success.

The change

One roster row plus its roster-list entry, in dag/gunbc/language_source_scaffold_index.dag:

data ct_row_ct_render_rust_applied_type_qualified_base_test: LanguageSourceScaffoldRow = LanguageSourceScaffoldRow {
  carrier_module: "v1.compiler.compiler_tests_rust", blob_decl: "ct_render_rust_applied_type_qualified_base_test",
  disposition: compiler_tests_rust_hand_assertion_scaffold_trigger
}

Disposition is precedent, not invention. compiler_tests_rust_hand_assertion_scaffold_trigger
is the existing disposition for hand-authored ct_*_test assertion blobs — 15 rows already carry
it, the most-used disposition in the file. The new blob is exactly that shape: a hand-authored
Rust #[test] asserting emitter behaviour. No new authority is minted and no existing binding is
changed.

Test plan — green by execution

./target/release/claim_batch --entry dag/test/claim/language_source_scaffold_index_test.dag --source-root dag --source-root src/v2 with all six witnesses in the file:

PASS compiler_tests_rust_blobs_are_all_rostered
PASS runtime_rust_blobs_are_all_rostered
PASS language_source_scaffold_roster_is_fully_dispositioned
PASS scaffold_binding_nothing_is_refused
PASS reasoned_terminal_is_accepted
PASS pair_completion_spelling_binds_the_derivation_authority

• Target witness GREEN (27 == 27)
• Sibling roster witness (runtime_rust) unaffected
• Roster-wide disposition witness green — the new row is dispositioned, not merely counted
• All three control witnesses still green — the fix did not slacken the checks

Binary receipt (the stale-binary trap is real here — the checked-out claim_batch predated
this work by six days, and a stale binary evaluating a roster count is exactly how a non-fix
"verifies"):

path	target/release/claim_batch
built	2026-07-26 13:58 UTC (was Jul 20 20:01)
size	20620416 (was 19510928)
sha256	a5b9eb4a064362138dcaf7a93d003996…

The RED half was executed by CI, not re-staged by hand

This PR adds no new discriminating RED, deliberately: the witness it repairs is the RED
control, and it has already fired twice on main by execution — failure at 0236b5048a and at
862bb773df, both compiler_tests_rust_blobs_are_all_rostered returning Bool(false). So the
red-before / green-after pair is complete and both halves were executed; only the red half was
executed by CI rather than locally. Deleting the row re-reds it (26 != 27).

Per the file's own coverage_scan_dissolve_on note, the counting mechanism is a declared interim
(source-text split rather than a Node-tree count, so it detects arrival of an unrostered blob
rather than classifying it). This change neither touches nor extends that debt.