Add channel-aware release tooling and updater recovery

release/SIGNING_MIGRATION.md

@@ -0,0 +1,35 @@
+# Manifest signing migration
+
+The installed launcher population currently pins the 3072-bit RSA public key in
+`ptlinux/launcher-update-public.pem`. Release scripts also support OpenSSL
+Ed25519 keys, but changing the Gitea secret before clients receive the new
+public key would make all metadata unverifiable.
+
+Use this staged migration when Ed25519 is adopted:
+
+1. Generate the Ed25519 key pair offline. Keep the private key out of the
+   repository and record the public-key fingerprint through the normal release
+   review process.
+2. Publish a normal RSA-signed transition release. That immutable archive adds
+   the Ed25519 public key and updater support, while its channel manifest still
+   verifies with the RSA key already installed on clients.
+3. Verify the transition release from a clean pre-transition installation on
+   both stable and prerelease channel paths. Confirm rollback still verifies old
+   RSA-signed historical manifests.
+4. Keep `manifest.json.sig` RSA-signed while enough installations move to the
+   transition release. If dual signatures are introduced, upload the Ed25519
+   signature under a separate filename; never change the meaning of the legacy
+   `.sig` asset for old clients.
+5. Publish a second RSA-signed release that makes the updater choose signatures
+   by an authenticated algorithm and key identifier, and bundles a keyring with
+   both public keys. Its minimum updater compatibility must prevent an older
+   verifier from trusting metadata it cannot authenticate.
+6. Replace the protected Actions signing secret only after the keyring release
+   is deployed and measured. Exercise stable discovery, prerelease discovery,
+   remote rollback, withdrawal publication, and tamper rejection with Ed25519.
+7. Retire RSA verification in a later release. Retain the old public key for
+   immutable historical rollback metadata until those releases are outside the
+   supported rollback window.
+
+At every stage, a failed or incorrectly signed tag remains immutable. Correct
+the pipeline and publish the next semantic version rather than replacing assets.