Proposal: V2 Release Workflows

**Problem:**
The existing release update process automation is a bit fragile today and will break when we have V1 and V2 releases happening concurrently.

**Why?**
Today what happens is:
- we click "publish" and a release goes live with no assets
- "release published" webhook fires, but IO ignores them because assets aren't ready
- the asset build workflow kicks off, assets get built then uploaded as artifacts to the release
- "workflow job completed" webhook fires, IO receives it
- IO does not know _which_ release or semver this is related to (that info is in "release" webhooks, not "workflow job" webhooks)
- IO naively fetches the latest release from github and assumes it is correct
- IO sets the semver related to that release as the new "current"

This is almost always correct today, where we only have on version line getting released, and releases are spaced out in time.

When we are releasing V1 and V2 lines, and often enough we'll release them concurrently for shared bugfixes, this will break down.

**Describe the solution you'd like**
Use this release workflow instead:
- prepare a draft release but do not publish it the standard way
- dispatch a workflow job that:
- builds the assets
- attaches the assets to the draft release
- publishes the release

IO can then listen for the "release published" webhook, knowing the assets are already attached to it. It can then extract the release semver from the webhook payload and import and bump the appropriate assets and semver.

**Alternative**
There appears to be a "prerelease" status for releases (maybe this is what is meant by "draft"? i don't know), perhaps the proposed workflow job could be automatically triggered by that release status.

The final ergonomics of releasing might not follow my proposal, the main goal is having the "release published" webhook fire ONLY after all assets are attached.

**Context**
[workflow job completed webhook payload](https://docs.github.com/en/webhooks/webhook-events-and-payloads?actionType=completed#workflow_job)
[release published webhook payload](https://docs.github.com/en/webhooks/webhook-events-and-payloads?actionType=published#release)

Start by reviewing the existing release update automation and the IO handlers for the “release published” and “workflow job completed” webhooks. Compare the proposed draft-release workflow with the prerelease alternative using the linked GitHub webhook payload documentation. Done means the published webhook fires only after assets are attached and IO identifies the correct release semver without fetching the latest release.

Written by the indexing model from the issue text.