Add reference-resolution and required-part conformance track (B1b-3b-1)

[gvonnessi]

Summary

Tier 3 part 2 of the document/part layer: the State Machine §5.4.2 rows for required and path-only-referenced parts, plus reference resolution over content and the out-of-hash annotation layers.

Until now a document loaded CLEAN with an absent or unparseable Dublin Core part, a #-anchor pointing at nothing, two blocks sharing an id, or a corrupt collaboration file. This closes both fail-opens B1b-3a recorded: the dcResolvable skip, which emitted nothing at all for an unloadable Dublin Core, and the swallowed duplicate-id canonicalization error.

Rows implemented (all draft/review; every frozen/published escalation stays in B3):

Row	Check	Disposition
309	Dublin Core unreferenced / absent / unparseable / missing a required term	WARNING
311	A path-only manifest reference whose target is absent	WARNING (state-invariant)
313	Dangling core anchor; dangling extension-block target field (separate code)	WARNING
316	Dangling extension cross-reference mark	WARNING (state-invariant)
317	Dangling anchor from an out-of-hash annotation layer	WARNING (state-invariant)
318	Out-of-hash extension data part present but unparseable	WARNING (state-invariant)
03a §7.2	Duplicate id in the shared identifier namespace	INTEGRITY-ERROR, every state

The id collision is the only INTEGRITY-ERROR this layer can assign before B2/B3, precisely because it does not vary by state. A mistyped metadata or metadata.dublinCore is the manifest missing-or-mistyping-a-required-field REJECT, distinct from genuine absence.

Reference resolution lives in a new pure module and resolves against the canonicalizer's own identifier namespace, never a re-derived one: alphaRenameIds' first pass is extracted into an exported collectDefinedIds over a shared walkContentNodes. Walking RAW stored content requires reproducing every canon transform that changes which ids exist — adjacent-text merging, mark dedup within a text node, and derived-field deletion, each scoped exactly as canon scopes it — or the resolver disagrees with computeDocumentId in one direction or the other. That agreement is asserted differentially in test-canonicalize.ts rather than against hand-written expectations.

Extension-block interiors are descended here, unlike in the block/mark classifier: the canonicalizer already resolves and relabels anchors inside them, so a check the document ID depends on cannot stop at their boundary. Out-of-hash anchors are resolved only at the positions the extension schemas declare — a generic sweep false-positives, since a phantom carries a full content tree and a collaboration change record carries verbatim block snapshots naming removed content.

Adds 10 errors.json codes (vocabulary v0.8), 21 fixtures, and independent oracle confirmers.

Three things worth your attention

1. A change to the hashing definition. inMarks now requires Array.isArray, matching rewriteIds' dispatch. This alters computeDocumentId output for a non-array marks (sha256:e6d63020… → sha256:60ed760a…). Only schema-invalid content is affected — content.schema.json types marks as an array — and the new behaviour is the correct one, but this repo has a no-signed-byte-drift discipline and the change rode in on a branch named for the reference resolver. Flagging it rather than letting it pass silently. Say if you want a document-id vector pinning it.

2. The oracle is a transliteration for this slice, not an independent implementation. Its ZIP parsing, duplicate-key scanner and confirm_clean aggregates remain genuinely independent and catch a fixture whose bytes do not carry the defect its case.json claims. But _walk_content / _merge_key / _collect_ids are ports of the TypeScript, and during review they reproduced two critical defects verbatim rather than catching them. For the raw-walk and merge logic the real oracle is the differential test against computeDocumentId. The "64 defects confirmed" figure should be read with that in mind.

3. Three spec questions, recorded rather than guessed at:

• §5.4.2 row 299 vs row 309. metadata.dublinCore is a required manifest field, so a manifest omitting metadata entirely also reads as the "missing a required field" REJECT. I took the more specific metadata row (WARNING) and authored warn-metadata-unreferenced as an interval [WARNING, REJECT] so the suite does not foreclose either reading. Your call whether to settle it.
• The footnote mark's target namespace. The mark carries an optional id, but semantic:footnote blocks match by number/symbol, so id addresses nothing clearly specified. Deferred outright.
• §5.4.2 row 318 vs semantic.schema.json. The row calls the bibliography/glossary side files "path-only", but the schema declares them {path, hash}, which the projector binds — making them row 310, not 318. Flagged rather than propagated into a published note.

Test plan

• check:conformance — 199 vectors + 98 fixtures
• check:document-oracle — 64 injected defects confirmed, 11 clean documents
• test:canonicalize — 96/96, including the differential raw-walk-vs-canon test
• check:document-id, check:canonicalize-oracle, check:manifest-projection — canonicalize-refactor regressions
• check:fixtures byte round-trip; check:enumeration-coverage; generate:template
• All 29 gates green locally
• Every new defense mutation-tested: disabling any check, erasure, or reference field fails the gate; both positive controls fail when flipped

Review history

Three /review-fix cycles across five independent reviewers found 4 CRITICAL defects that all green gates missed — three of them false or missed INTEGRITY-ERRORs caused by the raw walk diverging from canon, and one duplicate-key REJECT lost for parts not named *.json. Two were introduced by earlier fixes in the same run. All are fixed and mutation-verified.