ci(release): validate CARGO_REGISTRY_TOKEN against crates.io in the version-gate probe (security-08 gap)

[dean0x]

Context: the v0.4.0 tag-push release run 33569514359 (tag v0.4.0 at 6673dc3) passed version-gate, all 7 native builds, both musl link gates, the A3 name gate, and the new CI-history gate, then failed in "Publish to crates.io" at cargo publish -p mds-core with 403 Forbidden: authentication failed. Nothing was published (publish-npm and github-release were skipped), so the run is resumable with gh run rerun 33569514359 --failed after the secret is replaced.

Gap: the security-08 credential probe in version-gate verifies the npm token against the live registry (npm whoami) but only checks CARGO_REGISTRY_TOKEN for non-emptiness, so an expired or revoked crates.io token is discovered only at the first irreversible step. RELEASING.md already documents this asymmetry.

Proposal: in the probe, call curl -fsS -H "Authorization: ${CARGO_REGISTRY_TOKEN}" https://crates.io/api/v1/me and require a 200 with a user.login field (fail closed on anything else; never echo the token or the response body beyond the login). Optionally also assert the token can see the crates it must publish via cargo owner --list mds-core --token ... (read-only). Note the crates.io API requires a User-Agent header (curl sets one); document the rate limit. Mirror the check in RELEASING.md's dry-run paragraph so a dead token fails the pre-tag dry-run, matching the npm behaviour.

Acceptance: a revoked token fails the workflow_dispatch dry-run in version-gate with a clear ::error:: before any build; a valid token prints the crates.io login; RELEASING.md updated; verified by a branch dry-run with a deliberately invalid token (positive control) and with the real token.

Relates to #344, #342, PF-023.

[dean0x]

Closing as not planned (won't-fix-as-filed); re-scoped to documentation in PR #369 (squash ee569f5).

Why the probe as filed cannot be built (verified live 2026-09-07 against rust-lang/crates.io main):

• GET /api/v1/me is AuthCheck::only_cookie() (src/controllers/user/me.rs:38-41); a valid API token, scoped or not, gets HTTP 403 "this action can only be performed on the crates.io website" (src/auth.rs:136-144).
• A token that fails crates.io's format check gets HTTP 401 "The given API token does not match the format used by crates.io…" (src/auth.rs:295); a well-formed token that is not in the database (deleted/revoked) gets HTTP 403 "authentication failed" (src/auth.rs:297-303). The live probe with a bogus header returns 401, not the 403 this ticket assumed.
• The only token-accepting read route, GET /api/v1/me/tokens/{id} (src/controllers/token.rs:269-282), accepts legacy unscoped tokens only; a scoped token gets HTTP 403 "this token does not have the required permissions". There is no read-only probe for a scoped publish token. Every request also needs a User-Agent (src/middleware/require_user_agent.rs:35-47).

So the non-empty guard in version-gate is the strongest general check available, and a revoked token is first detected at the first cargo publish — fail-before-write, after the build matrix has run (precedent: v0.4.0 run 33569514359 attempt 1 failed at Publish mds-core with 403, nothing was published, gh run rerun --failed completed it).

What landed in #369: the guard comment in version-gate now says exactly this; spec S3 pins the executable if [ -z "$CARGO_REG_TOKEN" ]; then line (planted-control proven red); RELEASING.md's credential-probe section states what each of the three registry checks proves; prerequisite 3 says to verify the token in the crates.io UI before tagging (PF-023); and the fork/Dependabot paragraph now says a fail-closed Version gate blocks the merge on release-surface PRs.

Durable fix: crates.io Trusted Publishing (OIDC) via rust-lang/crates-io-auth-action, tracked in #368.