ci(release): harden publish job — retry verify, explicit checkout token

[imarios]

Why

The Release workflow's publish job has had recurring failures across recent runs (5 of last 20 runs). Two distinct fragilities, both fixable in a few lines:

1. CDN propagation race — Verify published packages does sleep 10 && npm view. The npm registry CDN can take 30–90s to propagate a new version, so this races and 404s on otherwise-successful publishes. Real examples:

   • #26196949274 — v0.36.2 verify failed with E404 after publish succeeded
   • #26059609274 — same pattern

2. Implicit checkout token — actions/checkout in the publish job relied on the default token. The sibling release job sets `token: ${{ secrets.GITHUB_TOKEN }}` explicitly; matching that removes a known intermittent auth path. Real example:

   • #26340559368 — v0.38.1 failed checkout with `fatal: could not read Username for 'https://github.com': terminal prompts disabled`. Recovered by rerun only.

The retry pattern already exists in `.github/workflows/publish.yml:64-75` — this PR ports it verbatim into `release.yml` so both publish paths converge on the same hardening.

What changed

• `.github/workflows/release.yml` — replace `sleep 10 && npm view` with the 6 × 15s retry loop (≈90s cap), matching `publish.yml`.
• `.github/workflows/release.yml` — add explicit `token: ${{ secrets.GITHUB_TOKEN }}` to the publish job's `actions/checkout`, matching the `release` job.

How tested

• `git diff --stat`: 1 file, +14 / -4. Reviewed top-to-bottom.
• YAML validated structurally with `yq '.jobs.publish.steps[]'` — all step names still resolve.
• Pre-commit hooks (yaml, biome, tsc, commitizen) all green on commit.
• No application-code change → no `bun test` impact.
• Real verification: the next merged commit to main exercises this workflow end-to-end.

Risk & rollback

Low. CI-only change. Worst case: the retry loop masks a different propagation issue and we get a 90s wait instead of 10s before failing — strictly better than today. Revert: `git revert `.