Toolkit migration invariants

Treat Toolkit migration as a hard gate: first ship a backward-compatible getsentry/cli stable release, then import CLI and docs history separately into packages/cli and apps/cli-docs. Probe Toolkit before legacy and fall back only on a typed HTTP 404; transport, authentication, rate-limit, and server failures are terminal, and never infer fallback from message text. Reuse the successful probe and preserve source affinity through validation, release notes, GitHub/GHCR, delta chains, caching, prefetch, nightly, downloads, and offline resolution. Normalize Toolkit’s cli@ tag only at the GitHub-release adapter boundary without changing selected-source URLs, assets, or cache keys. Keep TypeScript and installer sources synchronized; fresh installers stay single-source and mutable URLs switch only at cutover. Dual-publish identical stable and nightly artifacts for at least two releases and about 90 days; retain writable legacy until telemetry and release evidence support archival. Test ordering, affinity, fallback, failures, tags, and offline behavior.