toolkit merge: bridge CLI release + dual-source upgrade compatibility #1244

Sub-task of the toolkit monorepo merge: #1248.

Goal

Ship one stable bridge CLI release from getsentry/cli before any CLI history is imported into getsentry/sentry-mcp. The bridge release must remain usable before the Toolkit rename and must discover releases from Toolkit after the rename. Older binaries must continue upgrading through the legacy endpoints.

This is a hard prerequisite for the repository merge.

Ordered source contract

• New binaries and the install script always check the ordered source list:
  1. getsentry/toolkit / ghcr.io/getsentry/toolkit
  2. getsentry/cli / ghcr.io/getsentry/cli
• Fall through to the next source only on HTTP 404. Network and fetch failures remain transient errors; they never poison a source.
• Use one shared source definition for TypeScript and the generated install script. A check must fail if the two lists or their ordering diverge.
• Old binaries only know getsentry/cli, so every migrated CLI stable release and nightly must be dual-published to Toolkit and the legacy CLI endpoints during the compatibility window.

Implementation

• Add UPGRADE_SOURCES across src/lib/binary.ts, ghcr.ts, upgrade.ts, and delta-upgrade.ts.
• Mirror the same ordered fallback in the install script.
• Add a check: script proving the install script and TypeScript resolver use one ordered source list.
• Preserve delta-patch chains (sha256-<binary> / from-version) and cleanup/keep-count parity across both GHCR packages.
• Configure the post-migration Toolkit release flow to dual-publish releases and nightlies to both repositories. Keep getsentry/cli writable until this window ends.

Bridge release gate — before CLI import

• Cut the next stable CLI release from getsentry/cli with the dual-source resolver. Do not pin a target version manually; use the release system computed version.
• Verify a pre-bridge binary upgrades to the bridge release through getsentry/cli.
• Verify the bridge binary handles a 404 from the not-yet-existing getsentry/toolkit source and upgrades through getsentry/cli.
• Verify the install script has the same behavior.
• Record the released bridge version here. Only then begin toolkit merge: import CLI into sentry-mcp, validate, then rename #1239.

Post-rename compatibility matrix

• Publish one staging CLI release from Toolkit to both repositories.
• Verify a pre-bridge binary upgrades through getsentry/cli.
• Verify the bridge binary and a Toolkit-built binary upgrade through getsentry/toolkit.
• Simulate a Toolkit 404 and verify both new binaries fall back to getsentry/cli.
• Compare release assets, SHA-256 values, GHCR manifests, and delta-chain metadata between both repositories. They must match.
• Run the same matrix for the install script and one nightly.

Sunset

Keep dual-publishing for at least two stable CLI releases and roughly 90 days of nightlies. Archive getsentry/cli only after telemetry and release evidence show the legacy endpoint is no longer required; until then it must remain writable.

See the master sequence in #1248.