fix(ci): make RC latest recovery failure-tolerant

[yamcodes]

Summary

Follow-up to #1972 addressing the Pullfrog review that landed after CI went green (and was missed before merge), plus the follow-up review on this PR.

1. Failure-tolerant npm recovery — Point latest at current @rc uses !cancelled() && (success() || failure()), matching Mark-workspace.
2. Partial publish gap — Point latest at published RC gets the same gate. changesets/action can set published=true then exit non-zero; without this, primary retag skipped by success() and recovery skipped by published != 'true'.
3. Recovery scope confirmed — every-v1-push --from-rc / --from-workspace while pre/rc is intentional; documented in workflow + RC_CHECKLIST.md §C.

No changeset (CI/docs only).

Test plan

• Diff review of release.yml gates
• RC checklist wording covers primary + recovery failure-tolerant paths
• Do not merge until you say so

Related: #1972

  

[changeset-bot]

⚠️ No Changeset found

Latest commit: e47089a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pullfrog]

ℹ️ No critical issues — one rough edge in the recovery coverage.

Reviewed changes — full diff (2 files, 1 commit) for the RC latest recovery follow-up.

• Failure-tolerant npm recovery — Point latest at current @rc now carries !cancelled() && (success() || failure()), so a run where an earlier step (including Changesets) fails still attempts the retag, matching the Mark workspace GitHub prereleases as Latest sibling.
• Scope documentation — new workflow comments and RC_CHECKLIST.md §C wording record that the every-v1-push --from-rc / --from-workspace retag while pre.json is pre/rc is intentional, plus the NPM_TOKEN failure caveat.

ℹ️ A partial publish still skips the npm retag

The failure tolerance landed on the published != 'true' recovery step only. The primary Point latest at published RC step (release.yml:95-96) still has just if: steps.changesets.outputs.published == 'true', so it inherits the implicit success() gate — and changesets/action sets published = "true" before it exits non-zero on a partial publish. That leaves published == 'true' on a failed step, so the primary retag is skipped by success(), the recovery step is skipped by published != 'true', and only the Mark-GitHub sibling runs. npm latest then trails the previous RC until the next v1 push (which does recover).

Technical details

# Cover the `published == 'true'` failure path too

## Affected sites
- `.github/workflows/release.yml:95-96` — `Point latest at published RC` (`if: steps.changesets.outputs.published == 'true'`) has no failure-tolerant guard, so it is skipped when the Changesets step fails.
- `.github/workflows/release.yml:111-119` — the `published != 'true'` recovery step is now failure-tolerant, but its condition excludes the `published == 'true'` case.
- `changesets/action` v2.1.1 `src/index.ts` — after `runPublish`, it calls `core.setOutput("published", "true")` / `published-packages` and only then `process.exit(result.exitCode)` when the publish script exited non-zero. `runPublish` returns `published: true` whenever any `git-tag` event was emitted, i.e. some packages published.

## Required outcome
- When the Changesets step fails but reports `published == 'true'` (partial publish), `latest` is retagged to the just-published RC on the same run instead of waiting for the next `v1` push. This matches the sibling `Mark GitHub prereleases as Latest`, which already runs under that condition.

## Suggested approach
- Add `!cancelled() && (success() || failure()) &&` to the `Point latest at published RC` step's `if`, mirroring the recovery step. The `published == 'true'` vs `published != 'true'` conditions stay mutually exclusive, so there is no double retag.

## Open questions for the human
- Is the current asymmetry (GitHub Releases updated, npm `latest` stale until the next push) acceptable because it self-heals on the next `v1` push, or should the primary step be made failure-tolerant now?

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

[yamcodes]

Addressed Pullfrog’s partial-publish gap:

• Point latest at published RC now uses !cancelled() && (success() || failure()) && published == 'true', matching Mark GitHub / recovery siblings.
• That covers the case where changesets/action sets published=true after a partial publish and then exits non-zero (primary + recovery were both skipping before).
• RC checklist wording updated to mention both retag paths.

Still waiting for your merge go-ahead.

[pullfrog]

✅ No new issues found.

Reviewed changes — incremental since the prior pullfrog review (1 commit, 52d15fc → ff20c46, .github/workflows/release.yml only).

• Failure-tolerant primary retag — Point latest at published RC now carries !cancelled() && (success() || failure()) && steps.changesets.outputs.published == 'true', so a partial publish that sets published = "true" and still exits non-zero retags npm latest on the same run instead of trailing until the next v1 push. This is the exact fix the prior review's ### ℹ️ section asked for.
• Rationale comment — the new comment above the step records the partial-publish failure mode and points at the Mark GitHub prereleases as Latest sibling for parity.

The published == 'true' and published != 'true' conditions remain mutually exclusive, so the primary and recovery steps cannot both fire in one run, and the gate now matches all three sibling steps.

  ^{｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}