D6 — Decide the update path for a packaged install

[eaitbrahim]

PRD §4 (D6). A product decision before it is a code change.

The problem

keel update hard-refuses a bundled layout, twice over:

• deployment_layout_refusal (keel/commands/update.py:280-317) requires the running package to resolve from <launch>/.venv/…/site-packages/keel. A frozen bundle has no site-packages in that shape.
• _uv_install (keel/commands/update.py:577-581) requires uv on PATH — "uv is not on PATH — the updater installs with uv pip install". A desktop user has no uv.
• It is also gated by _require_interactive_confirmation (update.py:967), so it fails closed without a TTY (see D3 — A GUI human gate, architecturally distinct from _is_interactive #436).

Two options

A — Per-release installer (cheap). The desktop product has no self-update; each release ships a new signed installer, and the app notifies when a newer version exists. Costs the user a re-download; costs us nothing beyond a version check.

B — Bundle-aware self-update (expensive). Verify a signed manifest, replace the .app/.exe in place, handle macOS's restrictions on an app replacing itself while running, re-notarise per release. os.execv relaunch (update.py:895-926) behaves less cleanly for a frozen GUI binary than for a CLI script.

Recommendation: A. B buys convenience and costs an update channel that must itself be secured — for a tool that moves real money, a user deliberately downloading a signed installer is arguably the better trust posture anyway.

Either way

The existing keel update path for uv-venv deployments stays exactly as it is. This issue is only about what the packaged product does, and its refusals should name the desktop path rather than telling a desktop user to install uv.