feat(update): self-update — pull, deploy into the launch folder, relaunch (#415)

[eaitbrahim]

What

The console keeps the deployment current (#415): keel update (CLI) and the TUI Account menu's update entry — one service, two front-ends, fail-safe by construction. keel/commands/update.py is pure orchestration over subprocesses/HTTP; both front-ends render the same plan (render_plan_lines), run the same run (run_update), and ask the same typed gate (typed_update_gate — the CLI's own _require_interactive_confirmation, failing closed off a TTY).

• latest_release(fetch=...) — the public GitHub releases API, no auth, no secrets; honest errors for network, rate-limit and unexpected payloads.
• plan_update(release, ...) — current vs latest (semver; a release supersedes its own pre-release, junk tags refuse rather than guess), the four production wheel assets, the Release/ dir under the launch folder, every keel*.db to back up, the RUNNING venv, and offered/refused with a reason for every refusal.
• run_update(plan, *, echo, confirm_gate, download/install/migrate/verify=...) — the runbook's manual procedure, in its order, each step streamed, each failure honest.
• relaunch_tui(venv, argv) — the execv closure (pure construction; the new venv's keel entry carrying the original TUI argv, falling back to [keel, tui]).

The fail-safe contract

• The gate runs inside the service — run_update takes confirm_gate and calls it before any mutation: there is no ungated path to the writes. Never automatic, always typed, fails closed off a TTY.
• Backups first — every keel*.db in the launch folder is copied to <db>.bak-before-<version>-<ts> before anything downloads or installs (pinned by a test that asserts the backups exist from inside the install seam), and backups are never deleted.
• The four production wheels only — keel_core, keel_broker_api, keel_broker_coinbase, keel_trader by exact name, never Release/*.whl: the fake and Robinhood wheels can never ride along (RELEASING.md's rule).
• Install by path into the RUNNING venv via uv (uv is a deployment dependency of self-update; an absent uv is an honest error naming the manual procedure), then keel migrate --db each database with the new build.
• Verify before cleanup — the new venv's keel versions must report every keel distribution at the target; only a verified success removes the superseded wheels.
• A failed verify is loud, never papered over — pip has already replaced the packages, so the updater says exactly that state, re-installs the previous wheels best-effort while they remain in Release/ (they do — cleanup only happens on success), and names the manual recovery.

Refusals and the relaunch split

Dev/source checkouts are refused (not a release build; nothing installed; or the running keel package resolving from the launch folder itself — the uv run keel case). The TUI relaunches itself on a verified success (os.execv the new build's entry, terminal restored first, original TUI argv carried); the CLI prints the command and does not relaunch anything.

The audit surfaces

• Ceremony table: the Account update row (TYPED class) — the branch's one write path; its old "no mutating actions" pin became "exactly one, the typed update".
• Thinness pin: a new Rule 5 — no subprocess/urllib/execv anywhere in the console layer (the orchestration is the service's, which the pin doesn't scan), so no allowance was needed; the rule carries its own positive control.
• Runbook: "Self-update" under "Deploying a new version" (the procedure it automates), cross-linked with the console section; the typed-contract count and the Account-menu read-only claims updated to stay true.

Red-first throughout: the service's pure parts, run_update against a fake environment (ordering, verify-failure loudness + best-effort reinstall, superseded-cleanup-only-on-success, backups-never-deleted, the no-mutations --check spy, the closed-gate refusal), the relaunch closure, the TUI ARMED/typed/relaunch paths, the ceremony row, and the runbook pins all failed before the implementation landed.

Fixes #415