fix(release): release assets and notes inconsistent; pipeline incompatible with immutable releases

[tarotene]

Problem

GitHub Releases v0.1.0–v0.2.2 have inconsistent assets and release notes:

Release	immutable	Notes	Assets
v0.1.0	false	Empty	0 (pipeline not yet added)
v0.2.0	false	Correct	4 ✅
v0.2.1	true	Minimal (truncated)	0
v0.2.2	true	Broken header + wrong commits	0

Root causes

1. Structural incompatibility (critical): release-binaries.yml uploads assets via
   gh release upload after the release is published (release: published trigger).
   With immutable releases enabled, published = immediately locked → HTTP 422 on every
   upload attempt. This means no future release will ever get binaries without a fix.

2. v0.2.1 trigger gap: The release event from GITHUB_TOKEN-authenticated API calls
   is suppressed by GitHub's anti-recursion guard. The App token migration (ci(release-plz): migrate to GitHub App token so release PR CI and release-binaries both fire #206) fixed
   the forward path, but v0.2.1 was already published (immutable).

3. Changelog template bug: release-plz.toml [changelog] body generates a broken
   Markdown header ## [0.2.2]([`0.2.2`](url)) (backtick code spans inside a link
   break the Markdown). v0.2.2 also contains wrong commits (pre-v0.1.0 entries from an
   unconstrained git range).

Fix scope (one PR)

• Pipeline: Convert release-binaries.yml to workflow_call + workflow_dispatch
  (remove release: published). Add publish job: gh release edit --draft=false after
  all builds succeed.
• release-plz.toml: Add git_release_draft = true to telepath-wire package so
  release-plz creates a draft release. The release-binaries job attaches binaries to
  the draft, then publishes it (draft→publish before immutable lock).
• release-plz.yml: Add release-binaries job after release-plz-release; pass the
  resolved tag via workflow_call.
• Changelog template: Fix broken Markdown header and clean up CHANGELOG.md for
  v0.2.1/v0.2.2 with correct commit ranges.
• Docs: Update AGENTS.md and docs/releasing.md to reflect the draft→publish flow
  and recovery procedures.

Backfill (post-merge ops — tracked in this issue)

• v0.1.0: attach 4 binaries + add release notes (gh workflow run release-binaries.yml -f tag=v0.1.0)
• v0.2.0: fix "5 platforms" → "4 platforms" in release notes
• v0.2.1: update release notes to correct commit list + add disclaimer (immutable; assets cannot be attached)
• v0.2.2: update release notes to correct commit list + add disclaimer (immutable; assets cannot be attached)

Immutable releases — key constraint

Disabling immutable releases does not retroactively unlock already-immutable releases.
v0.2.1 and v0.2.2 are permanently immutable; their assets cannot be added even if the
repo setting is toggled. Only title and release notes can be edited.

Source: https://docs.github.com/en/code-security/concepts/supply-chain-security/immutable-releases

[tarotene]

Backfill status update

The following backfill ops have been completed directly (not requiring the PR to merge first):

• v0.1.0 — release notes added ✅; binaries ❌ (see below)
• v0.2.0 — "5 platforms" → "4 platforms" fixed ✅; 4 existing assets unchanged ✅
• v0.2.1 — release notes reconstructed from correct git range + immutable disclaimer ✅
• v0.2.2 — release notes reconstructed from correct git range + immutable disclaimer ✅

Unexpected: v0.1.0 and v0.2.0 became immutable after gh release edit

When I used gh release edit --notes-file to update release notes for v0.1.0 and v0.2.0,
both became isImmutable=true. This appears to be because gh release edit calls the
GitHub Releases PATCH API, which re-evaluates the immutable state under the current repo
settings — and immutable releases is now enabled for this repo.

Consequence: the v0.1.0 asset backfill (gh workflow run release-binaries.yml -f tag=v0.1.0)
now fails with HTTP 422 ("Cannot upload assets to an immutable release.").

v0.1.0 does not need binaries retroactively — the binary distribution pipeline was added in
v0.2.0 (#184), so v0.1.0 never had binaries and is not expected to have them. The release notes
now include a note: "Prebuilt binaries were not available for this release (the binary distribution
pipeline was added in v0.2.0)."

All four releases are now in a consistent, stable state:

Release	Notes	Assets	Notes
v0.1.0	✅ correct	—	Binary pipeline didn't exist yet
v0.2.0	✅ correct	4 ✅	First release with binaries
v0.2.1	✅ + disclaimer	0 ℹ️	Immutable; disclaimer explains why
v0.2.2	✅ + disclaimer	0 ℹ️	Immutable; disclaimer explains why

From v0.2.3 onward (after #223 merges), binaries will always be present: the draft→publish
pipeline attaches 4 assets before the release is published and locked.