Post-ladder master drift: seal-coverage red (dangling+phantom) and 'Every spec still generates' red (bigint.t27 et al.)

[gHashTag]

Both caught on PR #2230's merge-ref by the campaign's own gates; neither is caused by that PR (it touches only workflow apt steps + a skill doc), and neither job is in the required set. (1) coverage/'Every seal still describes its spec': new dangling/phantom seals after the reseal-post-ladder merge (#2224) — remedy per the gate's own vocabulary: remove seal with spec, restore both, or record deliberate debt in seal_baseline.txt via --update-baseline. (2) emit-bitexact/'Every spec still generates': specs/ternary/bigint.t27 parse error in fn jit_bind near line 539 (unexpected LParen after expression statement) and further specs — wave-landed specs that the current t27c does not parse; either fix the specs, fix the parser, or record in specs_generate_baseline.txt. Refs #2229.

[gHashTag]

Measured: 100 consecutive master runs, zero successes

Checked while diagnosing an unrelated PR block, so this is a bystander measurement rather than a fix.

Seal Coverage on master — the last 100 runs the API returns, spanning 2026-08-21 and 2026-08-22: 60 runs, 60 failures, 0 successes. There is no green run in the window at all, so "when did it break" cannot be answered from run history alone; it is older than the window.

Current failure text: FAIL: 136 seal(s) newly do not hold — "[]const u8".json [stale], Avgpool2d.json [stale], BootROM_Testbench.json [stale], and 133 more.

Two things worth separating, because they have different fixes:

• The gate is not required, so it does not block merges — three PRs merged past it today (docs(skills): classify the whole list, not its head #2434, fix(tools): the elaboration ratchet counted a phantom error per module #2435, fix(verilog): escape keyword-named identifiers where they are USED #2438) with it red. That is the milder reading and the more dangerous one: a permanently-red non-required gate is trained-to-ignore, and its next real finding arrives indistinguishable from its background noise.
• Its negative control passes. The same job logs self-check: 3 seals scanned; stale reported, missing-spec classified phantom (no history), good one silent = True. So the instrument works and is reporting something true — 136 seals genuinely do not describe their specs. This is not a broken gate; it is a working gate nobody can act on, which is Seals: 0 of 1072 specs verify, 928 with an unchanged spec_hash — gate it or remove it #2150's point restated with a number.

No claim here about the cause, and specifically not a claim that today's compiler changes did it: the failure predates the entire run window.