release: reconcile-stale-releases tags at main head instead of the release PR's merge commit

[JSONbored]

What happened

The reconcile-stale-releases self-heal (#7149) creates a missing tag for a merged-but-untagged release PR at the current main head, not at the release PR's own merge commit.

Observed live today (2026-07-24): the ui-kit v1.1.2 release PR (#8342) merged as 962fa08 during the afternoon's Actions runner starvation, so its release-please tagging run was cancelled before executing (ten consecutive Package Release Please runs were cancelled while queued). When the self-heal finally ran, it created ui-kit-v1.1.2 + the GitHub release at 16:37 pointing at d09fbe2 — main head, two commits later — which silently swept ddb674e (fix(ui-kit): declare react-hook-form as a dependency, #8494) into the 1.1.2 tag and the published artifact.

Consequences

1. Version-content drift: published 1.1.2 contains a commit that semantically belonged to 1.1.3. Harmless this time (a dependency declaration), but the same mechanism would happily sweep a breaking change into a patch tag.
2. Zombie release PR: the already-open v1.1.3 PR (chore(release): cut ui-kit v1.1.3 #8506) became permanently unreleaseable — release-please logs No commits for path: packages/loopover-ui-kit, skipping (the swept commit is now behind the tag) and neither regenerates nor prunes the PR, so its stale shared-manifest copy sat CONFLICTING with no self-heal path. Closed manually.

Fix

When reconciling a merged-but-untagged release PR, resolve the PR's merge_commit_sha and create the tag there, not at the branch head. If the merge commit can't be resolved, fail loudly rather than tagging head.

Acceptance criteria

• The reconcile path tags the release PR's merge_commit_sha.
• A regression test pins that the tag ref sent to the API equals the resolved merge commit, and that an unresolvable merge commit aborts without creating a tag.

[linear-code]

JSO-5902

[JSONbored]

Verified fully resolved — nothing left to implement.

The fix landed in #8527 (fix(release): tag and pack the resolved release commit, never the dispatch head), already merged to main, covering all four published packages (publish-engine.yml, publish-mcp.yml, publish-miner.yml, publish-ui-kit.yml) — each now resolves the commit that actually introduced the release version into its package.json via git log -S, verifies it's reachable from main, checks out and tags/packs that commit, and aborts loudly instead of falling back to HEAD if it can't be resolved.

The acceptance criteria's regression test also already exists: test/unit/publish-release-tag-pins.test.ts pins the resolver, the fail-loud-on-unresolvable contract, the ancestor check, the checkout-from-resolved-commit, the tag anchoring, and the pre-existing-tag comparison across all four workflows — 12/12 passing.

One residual, deliberately left alone: the already-published ui-kit-v1.1.2 tag/npm artifact still points at the old wrong commit (d09fbe22f instead of 962fa085d). Not retroactively correcting it — the content difference was harmless (a dependency declaration), and force-moving an already-published git tag/npm version is its own risk that isn't worth taking for a harmless past diff. The fix's value is entirely forward-looking, and it's confirmed working for all future releases.

Closing.