fix(update): install keel_broker_alpaca on self-update (#425)

[eaitbrahim]

What was wrong (confirmed, not assumed)

keel update on an equities deployment (config.paper-equities.yaml, broker: name: alpaca, keel-broker-alpaca installed in the venv) fails at verification, after the wheels are in, then reverts the whole deployment — exactly the "failure AFTER a finished install" path the issue suspected, not a silent mixed install and not an overrideable warning. The trace (line numbers from main):

1. plan_update → select_production_wheels picks exactly the four prefixes — the constant has no keel_broker_alpaca (keel/commands/update.py:87-92), the selection at :363-397, wired at :426. The plan is offered; nothing refuses.
2. run_update backs up the DBs, downloads those four wheels (:767-779) and installs them (:799-800, installed = True). keel_core / keel_broker_api / keel_broker_coinbase / keel_trader move to the new version; keel-broker-alpaca stays at the old one — nothing selects its wheel.
3. Migrate runs (schema-only, succeeds).
4. _verify_versions (:632-659) runs the NEW build's keel versions, which lists every keel distribution in the venv: the alpaca row is old (:649-651 → "keel-broker-alpaca is at X, not Y"), and keel versions itself exits 1 with PARTIAL INSTALL (keel/version.py:258, exit at keel/commands/versions.py:83) → UpdateError("verify failed: ...") at :659.
5. installed is True, so the post-install failure branch runs (:809, :839-877): the previous wheels are re-installed from Release/ best-effort (:840-845), rolled_back=True, and the error points at the manual runbook procedure. The new wheels stay in Release/; the backups stay.

So every self-update on an equities deployment fails and reverts, from v0.10.0 — the first release publishing keel_broker_alpaca beside a config that selects it.

The fix

keel_broker_alpaca joins PRODUCTION_WHEEL_PREFIXES (now five). Selection, install, the superseded set, cleanup and the verify floor all derive from the one constant, so the adapter moves with the rest and keel versions' all-must-agree invariant holds by construction. The plan/gate/manual-recovery wording that said "four" follows.

The "awkward part", addressed

The issue weighs three shapes and leans to (2) (install venue wheels already present in the venv, keeping four as the floor). This PR takes (3) (the named five-element constant), deliberately:

• The issue's cost argument against (3) — "a Coinbase deployment must not have Alpaca's requests dependency forced on it" — is void in fact: requests already rides every deployment transitively via the Coinbase SDK (coinbase-advanced-py depends on it; uv.lock). What (3) actually puts on a Coinbase-only box is one small unused adapter module.
• (1) (derive from the running config's broker: name:) couples the updater to config parsing — the plan could no longer state its wheel set without first reading a deployment's config.
• (2) is self-describing but makes the wheel set a per-deployment property: the gate wording and the runbook's named-path procedure could no longer state one list, and a deployment whose adapter was somehow missing would verify "healthy" (the remaining distributions agree) while its venue import stayed a release behind — the updater would have no way to heal it. (3) heals it.
• The deliberate exclusions stay excluded and stay named: keel_broker_fake (registers a fake venue entry point), keel_broker_robinhood (an Ed25519 stack for an adapter nothing constructs) and keel_broker_kraken (the just-merged stub, packages/keel-broker-kraken: a stub adapter — port implemented, every method raising NotImplementedError #313 — every data/market method raises; it must never ride an update). The #: docstring on the constant re-states all of it, including why the set is stated by name rather than derived; if a third real venue ever ships, (2) is worth revisiting.
• A test pins the set as an exact tuple, so any future venue is a deliberate edit to this list, never an accident of a glob.

Also stale (the issue's last section)

docs/RELEASING.md's "Release assets" table gains a keel_broker_alpaca-* row (a deployment installs it beside the four; keel update moves all five) and keel_broker_kraken-* joins the published-but-not-deployed row. The runbook follows: the manual procedure names the fifth wheel path (with the why), the keel versions sample shows five distributions, and the self-update section says five and names the kraken exclusion.

Tests (TDD: test commit first, then the fix)

• New: the wheel set pinned as an exact tuple — keel_broker_alpaca IN; keel_broker_fake / keel_broker_robinhood / keel_broker_kraken OUT.
• Extended: the selection test proves the excluded venues never ride even though the fake release carries them; verify is pinned to demand keel-broker-alpaca present at the target (the pre-fix "healthy" four-distribution output now fails verify); the run-order pin derives its download count from the constant instead of a hardcoded four; the runbook self-update pin demands the section name alpaca.
• Nothing else in code or tests assumed a count of four (["download"] * 4 and the len(...) == 4 in the zero-byte-download test were the only sites; both now derive).

Gates

• uv run pytest -q — 4348 passed, 3 skipped
• uv run ruff check keel tests packages — clean
• uv run mypy — clean (343 files)
• uv run ruff format --check on the touched files flags only hunks that exist identically on main (CI gates ruff check, not format); this diff adds none — verified by hunk-for-hunk comparison against the origin/main blobs.

Closes #425