feat: make the one-click update in Settings > About work under raven web

Start with ui-web/src/features/settings/pages/About.tsx and ui-web/src/state/upgradeShade.ts, then trace system.upgrade in raven/rpc/methods/system.py and update_notice._upgrade_command_works() in raven/updates/update_notice.py. Read SERVE.arm_hosted() in raven/rpc/serve_control.py, gateway _reload(), _refuse_incomplete_install, and raven/updates/upgrade.py before choosing the release or source-checkout scope; done means the chosen path is demonstrated end to end on the same port with documented refusal recovery.

Problem

Settings > About already offers a one-click upgrade: once a newer release is
known, an "Upgrade to X" button appears next to "Check for updates"
(ui-web/src/features/settings/pages/About.tsx), and it calls system.upgrade.
Under raven web, the normal way to run the WebUI, it can never succeed, and on
some installs it is offered where it cannot work at all.

1. system.upgrade refuses first with gateway_hosted whenever the page is
   mounted inside raven gateway (raven/rpc/methods/system.py), which is what
   raven web runs under its supervisor. The comment there calls restarting the
   gateway in place "a later phase".
2. Whether the button is offered is decided by
   update_notice._upgrade_command_works() (raven/updates/update_notice.py).
   Its docstring says editable installs are excluded; its body only checks for a
   uv tool receipt. An editable uv-tool install -- a source checkout installed
   with ./install.sh -- is therefore offered an upgrade that plan_upgrade
   always refuses ("Editable Raven installations cannot be upgraded
   automatically").
3. On a refusal the upgrade card offers one fixed fallback, raven upgrade
   (COMMAND in ui-web/src/state/upgradeShade.ts). That command refuses
   editable installs too, and under raven web it installs without restarting
   the running WebUI, so the complete manual sequence is raven web --stop,
   raven upgrade, raven web.
4. A source checkout has no update path from the page at all. For a checkout,
   "an update is available" means upstream main is ahead of it, not that a
   newer release tag exists.

For context: the latest stable release, v0.1.13, predates raven web (as
install.sh notes), so the first release that ships this page is the version a
page-driven upgrade will upgrade from.

Proposal

In order, smallest first.

A. Stop offering what cannot work, and name what does.

• Exclude editable installs in _upgrade_command_works(), as its docstring says.
• Give each system.upgrade refusal a reason-specific detail and a
  data.command that the card copies instead of the hard-coded raven upgrade:
  raven web --stop, raven upgrade, raven web for gateway_hosted, and
  git pull then ./install.sh (.\install.ps1) for an editable install.
• In the UI, translate the refusal reasons, and name the recovery command in the
  text shown when the page gives up waiting.

B. Make system.upgrade work under raven web for release installs.

• Give the hosted page a handle on the gateway's graceful shutdown.
  SERVE.arm_hosted() (raven/rpc/serve_control.py) takes none today, so
  request_shutdown() returns False there.
• Refuse with a busy reason while IM turns, sub-agents or pending questions are
  running, using the same test the gateway's _reload(force=False) already
  applies (raven/cli/gateway_commands.py).
• Have the existing detached helper (raven/updates/upgrade.py) wait on the
  supervisor's pid and relaunch raven web --supervise --port N from the new
  install, carrying RAVEN_SERVE_PORT_STRICT, RAVEN_SERVE_TOKEN and
  RAVEN_SERVE_COOKIE so the open tab comes back signed in on the same port.
• Make the gateway, or the supervisor before each launch, wait out the
  install-guard marker, as raven serve already does
  (_refuse_incomplete_install in raven/cli/serve_commands.py).
• Make a strict-port page-mount failure exit non-zero so the supervisor retries,
  and send the helper's output to a log so a failed install can be diagnosed.
• Rehearse end to end on a beta build before release: old wheel, click, new
  wheel back on the same port with the tab still signed in.

C. Optionally, a separate update path for source checkouts. Fetch upstream
main, refuse unless it fast-forwards a clean tree that is on main, rebuild
the TUI and page only when stale, reinstall only when the lock changed, and
relaunch as in B. The pull has to happen in the helper after the gateway exits,
never inside the RPC, and the page should be built into a temporary directory
and swapped in. This is roughly a Python port of install.sh and several times
the size of B.

Alternatives considered

• Teach the supervisor a "restart after install" exit code and have it re-exec
  itself from the new install, instead of the helper starting a fresh
  supervisor. It has more moving parts, and the supervisor holds its interpreter
  open while the environment it runs from is being replaced, which blocks
  uv tool install on Windows.
• For source checkouts, run install.sh from the helper instead of C. Less code,
  but it always force-reinstalls, can download Chromium, and writes no
  install-guard marker.

Area

Channels / gateway

Additional context

Costs of B that nothing in the tree addresses yet:

• every IM channel is offline for the whole uv tool install, which can take
  minutes;
• if the install fails badly the helper may have nothing to relaunch, leaving no
  WebUI and no rollback;
• other Raven processes that share the install, such as a second gateway or a
  TUI, are not stopped;
• Windows needs its own rehearsal before it is offered.

Open questions: whether the first version covers release installs only or source
checkouts too; whether a running IM turn, sub-agent or question should block an
upgrade or only warn; whether Windows ships in the first version.

The manual update steps are being documented on the quick start page in #711.