fix(release): run dispatch recovery from the current default branch

[chhoumann]

Supersedes the tag-source dispatch from #15, which was wrong: dispatching stage 3 on refs/tags/<version> (or release-run/<version>) executes the consumer's caller stub as it existed at the release commit - the historical toolkit pins - so a recovery could never pick up the very pin bump it exists for. Verified on PodNotes: the tag-dispatched release run called the reusable workflow at the old SHA.

Validate now selects the dispatch source by event:

• Merge event (and webhook redelivery): unchanged - pin the exact release SHA on the durable release-run/<version> branch and dispatch there, so a failed release stage is replayable at the exact source.
• workflow_dispatch recovery: dispatch stage 3 on the current default branch. The release stage then runs the consumer's CURRENT stub and pins (making "bump pins, then recover" effective), and its existing trusted-branch-recovery source check re-derives the release SHA from the PR, verifies any existing tag, and checks out the exact release commit for the build - fail-closed throughout. The recovery path performs no ref writes at all, which also sidesteps repos whose Actions token rejects createRef at older commits with differing workflow files (observed deterministically on PodNotes).

README recovery section updated to match.

Refs #9

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d981535a38

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve exact source when dispatching recovery releases

When Trigger release is re-dispatched after the default branch has advanced past the release commit, this dispatches stage 3 from the branch head instead of an exact release ref. The release workflow still builds releaseSha, but its resolve job records source-sha from github.sha and publish verifies attestations with that digest, so the published assets can be attested against an unrelated later default-branch commit rather than the commit that was actually checked out and built. Please keep the attestation source tied to releaseSha for this recovery path, or avoid using the moving branch ref as the attested source.

Useful? React with 👍 / 👎.