Fleet-prove --cli-install=binary live install path

[joshua-temple]

Context

#653 added --cli-install=binary, which emits a self-contained CLI install (no third-party action) that resolves the release tag, detects OS/arch, installs cosign by pinned checksum-verified download, and runs the embedded install.sh (sha256 + keyless cosign verify). Correctness of the emitted YAML is proven by actionlint and generator tests, and the verify contract is exercised hermetically by internal/setupcli.

What is NOT yet proven on real GitHub: the live resolve-tag + download + cosign-install + verify path, end to end. The e2e harness swaps the CLI install for a mock, and no fleet example repo currently opts into binary mode, so a normal fleet run only exercises action mode.

Ask

Add fleet coverage that generates with --cli-install=binary and runs a real scenario, so the live install path is exercised on GitHub-hosted runners. Options:

• Add a small binary-mode example repo to the fleet roster (fleet-e2e.yaml), wired like the others (token secret set when it joins the roster, branch protection to standard), OR
• Flip an existing lightweight lane to binary mode if that gives cleaner signal without a new repo.

Acceptance: a green fleet run that includes a binary-mode lane, confirming the resolve/download/cosign-install/verify steps succeed against a real release.

Notes

• The pinned cosign version (v2.4.3) and its per-arch sha256 in internal/generate/setup_cli_binary_preamble.sh are load-bearing; they were verified against the sigstore/cosign v2.4.3 release at merge time. Any bump must re-verify them.
• action mode is unaffected (byte-identical), so this is validation of a new opt-in path, not a regression risk to existing consumers.

[joshua-temple]

Validated via the cli-install-selftest workflow (#655) instead of a fleet member: cascade's own repo is a GitHub environment, and v1.0.0 is already published and signed, so a dispatch/schedule self-test proves both halves faster than a fleet run and with wider arch coverage than any single lane.

First live dispatch on main (run 29860198848): all four legs green, with evidence, not just a passing job:

• linux/amd64 and linux/arm64: cosign signature on checksums.txt verified. -> keyless cosign verification confirmed, cascade 1.0.0. The emitted binary-mode step ran keyless cosign against the real v1.0.0 release. The assertion fails closed if it silently falls back, so green means cosign actually verified.
• macos/arm64 and macos/amd64: proceeding on sha256 verification only -> documented sha256-only fallback confirmed, cascade 1.0.0. Binary mode has no pinned cosign off linux by design; the mandatory sha256 gate still passed and a working binary installed.

The workflow re-proves this weekly and on demand, so a future cosign bump or a change to the release asset format is caught.

Residuals (not blocking, folded out of this issue):

1. cosign verification is linux-only in binary mode (only linux amd64/arm64 carry a pinned cosign checksum). macos/windows get the mandatory sha256 gate but no provenance. This is now a tested, documented outcome. A followup can extend pins for full parity if anyone runs binary mode on non-linux runners.
2. An optional in-situ check (binary mode composing inside a full generated orchestrate run) can ride a nightly by flipping one light fleet lane to binary mode; low value versus the direct install-step proof here.

Closing as validated.