Prove stable release recovery does not require channel-note rewrites #604

🤖 Generated by the Agentic Engineer

Problem

Recovery #602 deliberately avoids rewriting semantic-release channel notes. That boundary currently rests on a disposable experiment rather than a maintained regression. A future dependency or configuration change could invalidate the assumption without required CI noticing.

Proposal

Extend the existing credential-free release-decision fixture using the shipped command and configuration. Exercise stranded stable tags with absent or matching default-channel notes, for both lightweight and annotated tags. At the tagged commit there must be no new version; one subsequent fix must choose exactly the next patch. Observe local and remote tag/notes refs and consumer files before and after each decision.

Acceptance criteria

• All eight native stable/default-branch decisions run through the existing offline reusable callers and required release controls; the command remains pinned to the production semantic-release version.
• The suite rejects an incorrect decision and any local/remote ref or working-file mutation, including channel-note changes. Negative controls must demonstrate rejection rather than merely inspecting fixture text.
• Missing/matching note cases and both tag kinds preserve their original source; no channel-note repair is performed by the release command.
• Document that GitHub publication, provider authorization, prereleases and multiple release branches remain outside this credential-free proof. Recover a missing stable GitHub publication without replaying release side effects #602/Complete release-recovery rollout and decide the opt-in lifecycle #603/Recover GitHub releases after a tag-only partial publication #587 stay open for their publication and consumer acceptance work.
• Review, merge, and observe the maintained fixture in hosted CI at the delivered head.

Refinement

Priority: High. Effort: Medium. Service class: Risk reduction. This is a separately deliverable safety regression for #602, not a recovery or rollout claim. No runtime feature or new dependency is introduced; existing offline callers already execute the fixture. The maintainer waived WIP limits for this round.

Part of #602.