Verify role-aware model URL, revision, and SHA pin parity

[leehack]

Problem

Draft PR #69 closes the original #52 gap by requiring the same seven model/projector SHA-256 values in all five pin files. It also compares each <ROLE>_SHA256 key between ci.yml and publish_assets.yml.

Two role-association gaps deliberately remain:

• swapping two SHA values identically in both workflows preserves their role-to-SHA equality;
• swapping values inside one or more Markdown command blocks preserves set equality because the bare --model-sha256 / --mmproj-sha256 flags do not name the model role.

The same five files also duplicate model/projector URLs, and the two workflows duplicate immutable 40-hex Hugging Face revisions. These values currently agree. A mismatch is caught later by checksum verification, so it fails loudly and cannot silently publish mismatched bytes, but the error is remote from the maintenance mistake.

This is follow-up hardening, not a blocker for #69: #52 asks for SHA set equality, all current role associations are correct, and #69 covers the release-risking one-workflow drift case.

Acceptance criteria

• Define a canonical role mapping for all seven model/projector pins without removing the runnable copy/paste commands from the docs.
• Verify role-to-URL/revision/SHA parity between .github/workflows/ci.yml and .github/workflows/publish_assets.yml.
• Verify each of the three Markdown command sets associates the expected role-specific model/projector path or URL with the canonical SHA.
• Add durable negative tests for a Markdown-only role swap, an identical cross-workflow role swap, URL drift, and immutable revision drift.
• Keep current checksums and URLs unchanged unless independently revalidated against the actual model bytes.

Evidence

An independent #69 review on 2026-08-23 confirmed the current tree is consistent. An in-memory contract probe confirmed the existing code rejects a one-workflow swap but accepts the identical-two-workflow residual described above.