Epic: first-class trusted publishing (OIDC) — doctor command, crates.io OIDC, first-publish detection, provenance surfacing

[goosewobbler]

From the July 2026 direction review (§1.1). The clearest differentiation window in the field: all three supported registries now do OIDC (npm GA 2025-07; crates.io live 2025-07; pub.dev since 2022, tag-triggered), no release tool owns it end-to-end, and post-Shai-Hulud registry policy churn (npm classic-token revocation, Dec 2025) is the moat argument against bespoke scripts.

Scope

• releasekit doctor (or publish --check-auth): per-package, per-registry check of trusted-publisher configuration; prints exact registry-UI setup steps and the required permissions: id-token: write block. Misconfiguration is the chore(deps): bump actions/download-artifact from 4 to 7 #1 OIDC failure mode.
• crates.io OIDC: close the token-only gap via the token-exchange flow (mint once, reuse across crates, revoke at end — release-plz's trusted_publishing.rs is the reference implementation).
• First-publish detection: all three registries require a manual first publish before OIDC works — detect and warn with guidance instead of failing cryptically.
• pub.dev tag-pattern fit: pub.dev OIDC only allows tag-push-triggered workflows; workflow templates need per-package tag patterns matching releasekit's tag scheme (+ optional GitHub-environment gating).
• Provenance surfacing: npm attestation links in release output — the user-visible payoff.
• Templates: packages/release/docs/ci-setup.md + templates/workflows/ default to trusted publishing per registry.
• Design note: shape the per-registry auth abstraction with the next registries in view (PyPI/JSR/NuGet/RubyGems are all variants of the same OIDC-exchange pattern) so later ecosystems are config entries, not redesigns.