Coverage residue from PR #118: checks that exist but do not reach part of their population #119

Two residues measured by the PR #118 review panel and deliberately left open there. Both are the same shape as the gaps that PR closed — a check that exists but does not reach part of the population it appears to cover — and both are documented in-code where they bite, but neither is tracked.

1. In-index asset hashes are unpinned on non-clean fixtures

PR #118 generalised check:fixtures's hash-coherence pass over every {path, hash} pair a manifest declares. It stops there deliberately: the asset entries listed inside an index file resolve their paths relative to the index's own location, and re-deriving that in the gate would duplicate asset-index.ts's resolution — the second-implementation drift this repo has been bitten by before. The architecture reviewer confirmed that boundary is drawn in the right place.

What it leaves: those hashes are pinned by the oracle's asset arms, and those arms run only on clean fixtures. So an asset whose bytes diverge from the hash listed inside an index is unpinned on a non-clean one.

Measured on integrity-error-id-collision-distinct-assets — corrupting its asset bytes leaves check:fixtures, check:conformance, check:document-oracle, check:document-id and check:structural all green.

Two fixtures are exposed today (integrity-error-id-collision-distinct-assets, warn-asset-listed-but-absent). The other asset-bearing non-clean fixtures are covered only incidentally, because they happen to be CLEAN_GUARD_CASES drivers — an accident that evaporates if a driver row is ever retired.

The boundary is stated in scripts/check-fixtures.ts with this measurement, so a reader is not misled. The question is whether to close it and how, given the resolution-duplication hazard is real.

2. Three oracle tag-emission sites survive both gates

conformance/oracles/document_oracle.py emits tagged findings from 27 out.add(...) sites. The tests reviewer neutered each in turn and ran both selftest() and check(): 24 die, three survive.

• :526 — out.add("mark_bare") for a non-object in a marks array. No fixture carries "marks":[42] or [null]. The CLEAN_GUARD_CASES comment claims one row per tag, which is true per tag, but this input shape has no driver anywhere.
• :1418 — out.add(v), the structural arm of _anchor_position_findings (in-hash CDX-E-ANCHOR-POSITION-INVALID). The TypeScript side is well covered (~10 assertions in test-document-verdict.ts), but the oracle's arm is confirmed by nothing — so the two implementations can silently diverge on the one code whose entire purpose is independent confirmation. It cannot be a fixture (null disposition, which the comparator cannot express), but it can be a selftest row given a fixture with a structurally bad in-hash position, or a driver constructed directly.
• :1630 — out.add(category) in _unresolvable_categories, the "indeterminate rather than dangling" suppression. Deleting it is invisible to every gate.

Why these are not in #112

#112's four original items are closed by #118, and its four remaining deferrals are a different set (OQ-012, the enumeration-coverage backtick gate, the rewriteIds link, the anchorTargets defaulting). These two were found by the #118 panel and belong on their own row rather than growing #112 into a catch-all.

Suggested order

Item 2's third bullet is the cheapest and the most valuable per line — _unresolvable_categories guards a suppression rule, and a suppression that nothing pins is how a real finding gets silently withheld. Item 1 needs a decision about the resolution-duplication trade before any code.