ci(release): drive release-please from the org config and manifest

[MotherSphere]

What changed

release-please configuration (REL-2, REL-3)

• release-please-config.json: verbatim copy of templates/release-please-config.json from Project-Colony-Resources (package ., release type rust, CHANGELOG.md, tags without component, no draft/prerelease/bump-minor-pre-major, the org changelog sections and the release PR header).
• .release-please-manifest.json: {".": "0.10.4"}, matching Cargo.toml on main and the latest tag v0.10.4.
• The action now gets config-file and manifest-file instead of release-type: rust. With release-type set, the action ignored config files, so release notes used the default sections ("Bug Fixes", documentation hidden).

Release workflow (REL-4)

• .github/workflows/release-please.yml is renamed to .github/workflows/release.yml and aligned with templates/sign-and-publish-caller.yml: concurrency: release-${{ github.ref }} with cancel-in-progress: false, the template's dispatch input description and comments (gh workflow run release.yml --ref vX -f tag=vX), actions/upload-artifact v7.0.2 (cf430e0), dtolnay/rust-toolchain at e2a55d2 (master, 2026-10-09) with toolchain: stable.
• Colony-specific parts are kept: the target job that refuses a published tag, the Windows version resource check, the --version smoke test, the Intel macOS architecture check, and the AUR publish after sign-and-publish. The shared workflow stays pinned at 619460f.
• aur-publish.yml names the new file.

Signing

• scripts/sign-release.sh (and with it scripts/) is removed. The COLONY_SIGNING_KEY_PEM organisation secret is the only copy of the key, and signing happens only in the shared workflow, so a hand-signing path cannot work and should not be documented.
• docs/release-signing.md is rewritten:
  • signature checks are not limited to the launcher: any app release that publishes <asset>.sig must verify against the same keys, and the signature and .meta requirements are pinned per app once verified (src/download.rs);
  • signing happens only in the shared workflow; recovery of a failed or partial release is the draft-release dispatch from the tag;
  • key custody is the COLONY_SIGNING_KEY_PEM org secret, not a file under ~/.config/colony/release-signing;
  • the rotation runbook now says that switching the org secret makes every Colony install still on an older version refuse every signed app, not only its own self-update, so a release carrying both keys must ship first; and it lists the copies of Colony's public key PEM that rotate with it (Resources templates/sign-and-publish-caller.yml and templates/program/README.md, each program's release workflow and README);
  • a Colony release that fails verification now blocks every program's release, since the template validates manifests with Colony's latest colony-linux.
• src/signing.rs: comments and one test name no longer refer to the deleted script.

Verification

• actionlint 1.7.12 on every workflow: clean.
• release-please-config.json is byte-identical to the Resources template; both JSON files parse.
• Pins checked against GitHub: actions/upload-artifact tag v7.0.2 is commit cf430e0, and dtolnay/rust-toolchain@e2a55d2 resolves.
• The PEM in the doc decodes to the 32 bytes of RELEASE_PUBLIC_KEYS in src/signing.rs.
• cargo fmt --check passes.

After merge, the release-please job on main should refresh #90 with the org sections ("Fixes", "Documentation") and keep the Cargo.toml and Cargo.lock bump. #90 is not merged as part of this change.