Update the floating release in place instead of recreating it

[excid3]

Problem

create-release deleted the floating release (e.g. 3.4.8) and its tag, then created a new draft. A draft has no tag, so the floating download URLs returned 404 from the delete until publish-release, about two minutes in a healthy run. If anything after the delete failed, the floating release stayed missing indefinitely. That is exactly what happened to every 3.x floating release in today's batch when the create call was rejected with a 403 (the token lacked the workflow scope needed because main had moved to a commit that changed a workflow file).

mise resolves versions that are not on the first page of releases (currently everything older than 3.4.0) through the floating tag, and cannot fall back to the pinned 3.4.8-N release on its own; a missing tarball means a source compile.

Change

• create-release only creates the pinned revision draft (e.g. 3.4.8-4) and cleans up leftover drafts with that tag from earlier failed runs. The floating release is not touched.
• upload-assets uploads tarballs and provenance to the revision draft only.
• publish-release publishes the revision first, then re-points the floating release at it in place:
  • existing floating release: delete assets this build no longer produces (and temporary names left by an interrupted run), upload the new assets under *.incoming, then per asset rename the old one to *.previous, rename the new one into place, and delete the old one. Each download URL is missing for one API call at most, instead of for a whole re-upload. Notes, title, latest and prerelease flags are refreshed and the floating tag is force-moved to the build commit.
  • no floating release yet: create it as a draft with all assets, then publish it, so it never appears without assets.
  • stale floating drafts left by the old workflow are deleted.

A failure anywhere in the workflow leaves the previous floating build serving.

Notes

• Publishing the revision before touching the floating release means the floating release never points at a build that does not exist, and clients that resolve revision releases (mise with MISE_LIST_ALL_VERSIONS=1, or a lockfile) see a rebuild as a new, complete, immutable release with no window at all.
• The floating tag moves on every rebuild, which is the intended semantics of a floating tag; consumers key on the asset URLs.
• README updated to describe the new ordering.

https://claude.ai/code/session_01KeNcsk8V24YRXGfD2HwDZY