Every composition dependency pin points at commit 56e02f9, which does not exist in this repository #21

The composition convention (improve-docker-security/modules/composition-convention.md) says a schematic-kind dependency is a link to the file at a specific commit plus the SHA-256 of its contents, and that verification is "fetch the raw file at the pinned commit, hash it, compare" (A-7 in every composition). Today that check cannot pass anywhere in the catalog.

What is wrong

All 21 pins across 8 packages use blob/56e02f9/.... That commit is not reachable from main and is not in the repository at all (git cat-file -t 56e02f9 fails; the first commit in history is 81721d8). The raw URL 404s, so every A-7 fails and build-schematic's reference check would too if it followed pins.

15 of the 21 hashes match the file as it exists on main (unchanged since 81721d8), so for those the fix is to re-point the commit only.

6 of the 21 hashes match no content that has ever been on main:

Those two compositions were built against contract text that was never published. The pre-rewrite content is unrecoverable, so the only recoverable state is a re-pin to what the catalog actually publishes, followed by a re-read of the six dependencies by the composition author to confirm nothing in the glue (parameter reconciliation, ordering, A-n cross-references) depended on the lost text.

Why nothing caught it

scripts/validate-catalog.sh checks names, sources, and the featured count. It does not parse pins. And nothing runs it (see the CI issue).

Fix

1. Re-point all 21 pins to 81721d8ff548ad0f4b1477e696b7899d30f999fa (the commit whose content the 15 matching hashes were computed from); refresh the 6 mismatching hashes to that commit's content and log the re-pin in each affected composition's Decisions section. Done in catalog: re-pin dependency links to a reachable commit; verify pins in CI #25.
2. Teach validate-catalog.sh to resolve every pin (commit reachable, path exists at that commit, sha256 matches) so a pin can never go dead silently again. Done in catalog: re-pin dependency links to a reachable commit; verify pins in CI #25.
3. Re-verify the six re-pinned contracts semantically. Done in catalog: re-pin dependency links to a reachable commit; verify pins in CI #25 (second commit), recorded in each composition's Decisions entry:

• run-a-movies-and-series-library re-read against fetch-movies-over-usenet, fetch-series-over-usenet, improve-docker-security as published. Every R-n, P-n, A-n, phase, and module reference resolves; MEDIA_ROOT-derived roots, category maps, and key rules agree. One drift found and fixed: Phase 0 still named D-2 and D-3 only ("two green lists") from before the fetching half was split into three packages; it now orders all four dependencies.
• run-a-music-library re-read against fetch-music-over-usenet, improve-docker-security, run-a-movies-and-series-library as published. R-1's reference to fetch-music R-1, the navidrome pointer to its Q-1, the shared-downloader module, MUSIC_ROOT/MUSIC_CATEGORY against its P-1/P-2, audio category 3000 against fetch-over-usenet P-6, and RD-3's D-3/D-4 note all resolve. No drift.

Remaining after #25 merges: a deliberate re-pin of improve-docker-security's D-3 to authorize-docker-requests 0.3.0 once #19 lands (the current pin to the v0.2.1 commit stays valid until then).