fix: stop rewriting dev during release publish

[kitlangton]

Summary

This fixes the release workflow bug where a long-running manual release can silently drop already-merged commits from dev.

The old flow created the release commit on a stale checkout, then tried to reconcile by cherry-picking everything merged during the build window on top of that release commit and force-pushing the result:

await $`git commit -am \"release: v${Script.version}\"`
await $`git tag v${Script.version}`
await $`git fetch origin`
await $`git cherry-pick HEAD..origin/dev`.nothrow()
await $`git push origin HEAD --tags --no-verify --force-with-lease`

If the cherry-pick stopped on a conflict or empty commit, .nothrow() swallowed the failure and the script force-pushed an incomplete branch. That's how #22926 and #22944 got dropped from dev after the v1.4.7 release.

New flow

This PR switches script/publish.ts to a two-phase model:

1. Release/tag commit

   • Keep building from the workflow kickoff snapshot.
   • Prepare versioned files on that snapshot.
   • Create the release: vX.Y.Z commit there.
   • Force-update the draft tag to that detached release commit.

2. Dev sync commit

   • After the release is published and package publish steps complete, fetch latest origin/dev.
   • Check out the current tip of dev.
   • Re-run the deterministic version bump on top of latest dev.
   • Create a fresh sync release versions for vX.Y.Z commit and fast-forward push it.

This keeps the semantics we want:

• The tag points at the actual released repo state (kickoff snapshot + version bumps).
• PRs merged during the build window stay on dev with their original SHAs.
• dev still ends with the release version bump, but we append it as a fresh commit instead of rewriting history to insert it earlier.
• No cherry-pick of in-flight dev commits.
• No force-push of dev.

Extra change

script/version.ts now creates draft releases with --target ${GITHUB_SHA} so the draft tag/release is explicitly anchored to the workflow kickoff commit instead of whatever happens to be the latest default-branch commit at that moment.

Trade-offs

This does intentionally create two version-bump commits during a release:

• the tagged detached release commit
• the later dev sync commit

That is a little ugly, but it preserves the two things we need simultaneously:

• the tag must describe the exact released tree
• dev must preserve all later merged PRs without rewriting history

Verification

• bun run lint script/publish.ts script/version.ts
• push hook ran bun turbo typecheck