docs(releasing): record that provenance is per-package npm config

[ChessMess]

Documentation only. Audited after noticing only 1 of 9 published packages had ever produced a provenance attestation — 71 versions, 7 attested, all of them ultimatedarktowerboard.

Nothing in the repo explains it

repository fields, publishConfig, prepack hooks and NPM_CONFIG_PROVENANCE are identical across all nine, and the release log shows no provenance error, warning or skip.

The cause is npm-side: Trusted Publisher is a per-package setting naming an exact repo + workflow file. When the OIDC claim (workflow_ref: .github/workflows/release.yml) doesn't match the package's entry — or no entry exists — npm can't mint the attestation and silently falls back to the NPM_TOKEN auth the workflow also supplies.

Two distinct faults, and the second was the common one

Fault	Packages
No entry at all	6 — game-data, relay-{client,core,shared}, mcp-server, relay-cli
Stale entry	2 — ultimatedarktower → publish.yml (deleted 2026-07-11); ultimatedarktowerdisplay → ChessMess/UltimateDarkTowerDisplay, the archived pre-consolidation repo

board was the only correct one, configured 2026-07-12 — the day after the workflow rename — which is why it alone produced provenance.

What the section adds

• Diagnosis from the registry, not the repo — count attested versions, then decode a working attestation to see which workflow actually produced it (both curl | jq one-liners included)
• The exact field values that work, as a table
• Two traps found while fixing it: entries are immutable, so a wrong one must be deleted and re-created; and Environment must be left blank, because release.yml declares no environment: key — filling it in breaks the claim match silently
• npm permits multiple entries per package, so a correct one can be added alongside a stale one without deleting anything — which matters, since every write costs a 2FA security-key tap

All nine packages have since been configured and verified; the next release of each will carry provenance.

Closes the loop on the replication-lag section from #101: that one was about misreading a good publish as failed. This one is about a publish that really is missing something and never says so.

Authored via the GitHub API — local ~/Documents/ is currently unreadable to this session due to a macOS TCC permission, so the file was fetched, edited and committed remotely. Formatted with the repo's pinned prettier@3.9.6 and its .prettierrc.

https://claude.ai/code/session_01Br4DeujSD86Rj6uxYuTC2r