v0.9.2 — pinned Beeper, gated :next channel

Release-pipeline hardening: a pinned Beeper version, a gated :next channel, stronger release gates and failure issues, plus docs. PATCH per the versioning policy: release/packaging tooling only — no tool was added or removed, and the MCP tool set, Chat/Message schemas, HTTP API, and default ports are untouched; the running container is unchanged (the :next image channel is a new published tag, not new runtime behavior).

Added

• :next image channel + Beeper pin file. The Beeper version that ships is now pinned in a new repo-root file, beeper-version.txt (4.3.123), read by releases (from the release ref, so each tag carries its own Beeper and the weekly rebuild of a tag is reproducible), :edge and the PR gate via scripts/pinned-beeper-version.sh. A release ref without the pin file fails prepare (it never falls back to latest stable). A new beeper-next.yml workflow (weekly Mon 07 UTC + manual) builds master with the newest stable Beeper when it differs from the pin, runs the amd64 and arm64 gates, and publishes :next and :next-beeper-<version> from the single master commit the check job resolved, which both gates also build (never :latest, :previous or version tags). A beeper-update issue reports the outcome once per Beeper version. To promote a Beeper: change beeper-version.txt in a PR, merge, and tag a release. The artifact check is shared by both scripts via scripts/beeper-artifacts-lib.sh.

Fixed

• Weekly rebuild could ship a stale Beeper: the build cache reused an old download. The Dockerfile's default downloads Beeper from a fixed "latest stable" URL, so the RUN step's text never changed and cache-from: type=gha kept reusing the old layer (the v0.9.1 publish step logged DONE 0.0s and shipped Beeper 4.3.123 while stable was already newer). verify and publish could also build different Beeper versions, since verify-arm64 had its own cache scope (scope=arm64), which was empty on its first run, so it downloaded fresh while publish reused the shared cache. Fix: the Beeper version is now resolved once per run and passed to every build as BEEPER_VERSION (from the pin file beeper-version.txt for releases, edge and the PR gate, checked by scripts/pinned-beeper-version.sh, which confirms the x86_64 and arm64 artifacts for that exact version both exist; the newest stable is resolved by scripts/resolve-beeper-version.sh for :next only). A changed pin changes the cache key, and every job in a run builds the same version. The rolling default remains for local/manual builds. A failed or empty version read now fails the step instead of silently falling back to the unpinned download, and the PR gate (mcp-test.yml) builds the same pinned Beeper.
• Release gate now also checks the API is reachable from outside and the container goes healthy. scripts/first-paint-check.sh publishes container port 23380 (the socat forwarder) on a loopback port and, after the paint check, requires /v1/info to return an app.version and the container HEALTHCHECK to report healthy — in the same single boot. Before, a broken forwarder or API would have passed verify. Assumes a fresh, never-logged-in Beeper 4.3.x starts its API without login (true on 4.3.123); if a future Beeper stops doing that the gate fails closed and publish is skipped.
• scripts/rfb.py reads the RFB handshake to full length. The version string, security-type count and refusal reason are read until complete or the peer closes, so a read split across TCP segments is no longer misjudged as "not an RFB server". Error messages unchanged.
• verify and verify-arm64 run with least privilege (contents: read). They only build locally and never push, so they no longer inherit packages: write.
• A failed release run now opens (or comments on) a GitHub issue. notify-failure in release.yml keeps its step summary and adds an issue labelled release-gate-failed, assigned to the repo owner, with the ref, Beeper version, trigger, per-job results and run link. If one is already open, repeated weekly failures comment on it instead of opening duplicates; closing it after the fix lets the next failure open a fresh one. If publish itself failed, the body says the push may be partial. The job gets issues: write + contents: read only.

Documentation

• docs/PRD.md version-history table brought up to 0.9.1 (it stopped at 0.8.0).