Update channels: per-PR prerelease builds in the self-updater

[kelchm]

What

Extend the self-updater (#95, PR #96) with update channels so new builds can be tested through the real update pipeline before a stable release exists — and so testers can ride a specific PR's builds without manual installs.

• Stable (default): current behavior — latest published release, unchanged.
• Per-PR channels: pushes to a PR publish a GitHub prerelease build (tag pr-<N>-<sha7>, asset FanaBridge-pr<N>-<sha7>.zip). The updater's channel picker lists stable plus one channel per open PR that has builds; picking one offers that PR's newest build.

Design notes

Modeled on the update-channel implementation in giantorth/AZOM (MOZA SimHub plugin), which runs this in production — with a deliberate divergence on retention (below).

• Everything stays an immutable, versioned release — no rolling tags, no re-uploaded assets. A cleanup workflow deletes a PR's prereleases + tags when the PR closes.
• Within a channel, newest build wins by published_at — no prerelease-suffix ordering, so no suffix-comparison edge cases.
• Stable selection gets hardened: fetch the release list, filter stable tags, take max by version (not list order), fall back to /releases/latest when a page is all prereleases. Prereleases remain invisible to stable users.
• Lifecycle is self-healing: a vanished PR channel (merged/closed + cleaned) falls back to stable, and the existing "release > its own preview" version comparison pulls channel riders back onto stable automatically once the next release ships.
• Integrity is unchanged and non-negotiable: exact asset-name match + GitHub per-asset digest verification apply identically to channel builds (digests are stamped on prerelease assets too). Channels change what is offered, never how it installs.
• Channel selection is opt-in, surfaced in the settings UI with clear "untested build" labeling; default remains stable.

Open question: build retention / releases-page visibility

AZOM retains every push's build as a separate release until PR close, which turns the releases page into pages of prerelease entries above the actual release — bad for the manual-install path (the README points users at the releases page). Decide at implementation time between:

1. One live build per PR, in-repo (current lean): each push deletes the PR's previous prerelease + tag and publishes the new one. At most one beta entry per open PR; plain GITHUB_TOKEN, no new infrastructure. Known benign race: a client holding a stale feed gets a failed download and re-checks.
2. Separate builds repo (e.g. FanaBridge-builds): main releases page stays stable-only; channel feed points at the other repo. Needs a cross-repo fine-grained PAT secret and its expiry upkeep.
3. On-demand rc prereleases only: no automated PR builds; cut v0.7.1-rc.N manually when a test cycle is wanted. Minimal page impact, loses the automatic per-PR test path.

CI

• PR-build workflow publishing the prerelease per push (reuses build.yml; skip fork PRs).
• Cleanup workflow on PR close.
• Release workflow unchanged.

Depends on #96.