#1265 Add the engine updater: verify, stage, all-or-nothing swap, rollback

本文

#1162 split in two so each half is reviewable on its own

The combined PR was +3005 lines across 9 files. The safety-critical engine mechanism and its tests belong to a
maintainer who wants to read the security model; the UI card is separable and thin. They are stacked - PR
"UI" is based on the "core" branch and lands after it - and they share the API routes in `server.py`, which
is the one place they legitimately depend on each other.

**PR A - the engine updater, `serve/` server-side, with the two checker scripts and the docs**

What it is: a new `serve/update.py`, the `/api/update/check|apply|state` routes in `serve/server.py`, the
four step labels enforced against the server responses (no drift), the two test files, and the documentation
of what the update does and how it was measured.

Why it is this shape, one paragraph:

> The engine is replaced in place, so the design's whole job is to never leave a mixture of two engines
> behind it. Nothing on disk changes until every check has passed (the archive's SHA-256 from the releases
> API, its own members' CRC and path checks, the version inside, whether this GPU has code in it, and the
> staged binary run with `--help` in the engine's own environment). Only then is the installed engine copied
> to `engine/.previous` - the same place, same generation, setup.py keeps - and swapped, all or nothing,
> under the service's own lock. A failure restores the backup *and removes anything the new engine added*,
> because restoring alone leaves the mixture. Measured live on the v0.1.40.1 release on this machine: 18 s
> end to end, the official CUDA 13 build was refused for this GPU, and a same-length different-content file
> was refused and deleted.

Tests: `serve/test_update.py` 143 checks, `serve/test_update_http.py` 51 over real HTTP handlers, no network.
`pytest serve` 473 passed, 8 skipped.

**PR B - the card** (base: `update-core`)

Adds the **Update the engine** card to the About tab, wired to the routes PR A provides. Each step carries
its own status and note from the server, and the `done` note names the engine version the install reported
back, not the release tag - the two are not always the same, and a hotfix release such as v0.1.40.1 ships the
v0.1.40 engine. Verified end to end in a browser against the live v0.1.40.1 release. Two live UI bugs were
found and fixed while doing that: a missed `bare()` strip on one writer that read `vv0.1.40.1`, and `/metrics`
polling overwriting the server's tag with BUILD.json's engine version, which could re-offer an update that
had already finished.

The base is `update-core` because PR B calls its routes; once PR A merges, GitHub will offer to rebase and
the diff shrinks to just the three web files. Nothing outside `serve/web/` is touched.