ci(docs): deploy docs site on release publish instead of every unstable push

[shane-moore]

Goal

Publish anchor.sigmaprime.io only when a release is published, so the live docs never describe CLI flags or download URLs that no public binary provides.

Context and motivation

docs.yml currently deploys to the live S3 bucket (with --delete) on every push to unstable. Operators see docs for unreleased flags weeks before a binary exists, and during each release window the site advertises versioned download URLs that 404 (the version bump merges to unstable before the release is published). Separately, the Linux example in installation.mdx omits the architecture from the tarball name, so that wget 404s permanently regardless of timing.

Suggested approach

• Trigger docs.yml on release: types: [published] plus a bare workflow_dispatch: escape hatch (manual redeploys; primary use is dispatching --ref stable after a docs hotfix is cherry-picked to stable).
• Guard prereleases in the existing job-level if (github.repository_owner == 'sigp' && !github.event.release.prerelease).
• Replace the per-ref concurrency group with a constant one (cancel-in-progress: false) so a release deploy and a manual dispatch cannot run s3 sync --delete concurrently.
• Fix the arch-less Linux download example in installation.mdx.
• Note the new publication timing in docs/README.md.

Acceptance criteria

• Pushes to unstable no longer deploy the docs site.
• Publishing a (non-pre) release deploys docs built from the release tag, with the released version in download URLs.
• Manual workflow_dispatch from a chosen ref redeploys the site; concurrent deploys serialize.
• The Linux install example downloads an artifact name that release assets actually use.

Tests

CI trigger changes are not integration-testable pre-merge: actionlint the workflow, then verify the first release publish after merge fires the deploy and the live site shows the released version and working download URLs.

Notes

• Rollout: the new trigger and the dispatch button only take effect once the file reaches stable (default branch) at the next release; until then the site freezes at its current content (status quo). Merging the change to unstable does not fire a final unstable deploy (push events read the workflow file at the pushed commit).
• push: branches: [stable] was the runner-up trigger; rejected because the release pipeline can fail after the ff-merge, leaving 404 download URLs live indefinitely. release: published fails safe (old site stays up). Also considered and rejected: a staging bucket for unstable docs (new infra; file separately if wanted), building from the latest tag on unstable pushes (redundant deploys), "unreleased" banners (doesn't fix 404s).
• Adversarially reviewed (Codex, 2 rounds, converged): concurrency and prerelease hardening above came from that review; "verify the published release is the latest before deploying" was considered and rejected as complexity without a current problem (a stale-draft publish is recoverable via dispatch).
• Deliberate deviation from sigp/lighthouse, whose book deploys from unstable: Anchor's docs embed versioned download URLs and a generated CLI reference, which makes unstable-tracking docs actively misleading.

Issues are directionally correct, not prescriptive; verify symbols at PR time.