Release automation: publish SHA256SUMS + canonical commit SHA; pin installer/README to a release

[mogul]

Context

Follow-up from #387 (installer + ADR docs/adr/0026-installation-and-distribution.md, accepted).

Two integrity mechanisms are already built in install.sh and just need release artifacts to point at:

• Commit-SHA pinning — --sha / ACQ_INSTALL_SHA checks out a full 40-char commit and verifies HEAD matches it, failing closed on mismatch. Content-addressed, so a matching SHA is itself an integrity check.
• Ref pinning — --ref targets a tag/branch (default currently main for pre-merge testing).

What this issue tracks

1. Publish SHA256SUMS for install.sh (and any release tarball) as a GitHub Release asset on each release.
2. Emit a canonical commit SHA per release so the installer can default to that SHA rather than a movable ref.
3. Swap the README install URL from .../main/install.sh to a pinned release tag (README.md lines that curl the raw install.sh).
4. Default the installer to the canonical release SHA (wire the already-built --sha path to the published value).

Blocking dependency / trigger

Blocked until a release that actually contains install.sh exists (chicken/egg: the README can't point at a tag before a release ships the installer). Trigger: the first release cut from main after #387 merges.

Acceptance

• Each release attaches SHA256SUMS; the hosted raw install.sh URL is pinned to a tag in the README.
• install.sh defaults to the canonical release SHA and verifies it (the --sha verification path already exists and is tested).
• "Live end-to-end" validation from ADR-0026's Validation section (hosted-URL + checksum flow) can finally run.

Notes

• release-please (release-type: simple) already bumps package.json version via the extra-files entry added in feat(install): add auto-selecting curl|sh installer + streamline README #387.
• Rationale: docs/adr/0026-installation-and-distribution.md (Security posture + Validation + Deferred sections).

AI-assisted (OpenCode). Human owner: @mogul.

[mogul]

Adversarial review of #387 flagged that the installer's default REF is main (a moving target) while the code comment and ADR claimed it was pinned. Resolved in that PR by making the claim honest: the comment and ADR-0026's Security-posture section now state plainly that main is the intentional pre-release default (there is no release tag that even contains install.sh yet, and the README curl URL fetches from main too), that this is not a pinning guarantee, and that --ref/--sha are the opt-in hardening available today.

This issue owns closing that gap. Concretely, the release automation here must flip the default from main to a pinned reference — set the installer's default REF/SHA to the canonical release tag + commit SHA at release time (analogous to how release-please-config.json's extra-files entry already keeps package.json's version in sync), and move the README raw-URL to the same tag in lockstep. Until that lands, the default install remains as unpinned as the msb bootstrap, by design and now documented as such.

[wz-gsa]

Confirming this covers the exact gap from my #387 review (changes-requested): install.sh still defaults REF to main on current main (verified), which is unpinned by default despite the script's own comment claiming otherwise. Good that this is already tracked with the correct blocking dependency (a release containing install.sh must exist first) — not duplicating, just cross-linking so it's visible from the review.