keel's web UI rewrite has merged to main — resync the browser-app copy when it releases

[eaitbrahim]

What happened

While syncing the site against keel for #86, I found my local keel clone was 12 commits stale. The real delta since v0.11.2 is 17 commits, not 7 — and the web UI rewrite, which read as a Status: proposal design document, has since fully merged to main.

de5c326 feat(web): delete the renderer -- the server serves files and JSON, and nothing else (#540) (#553)
8a973e4 feat(web): installable, with a worker that structurally cannot cache a balance (#538) (#551)
3a9a816 feat(web): the remaining six views, an SVG curve nobody has to see... (#550)
268fe06 feat(web): the client shell, in the four modules the spec names (#536) (#549)
fe43a27 feat(web): serve the reports as JSON, sorted with Decimal... (#547)
151f2f2 feat(web): serve static assets, with the headers that make the UI's reach checkable (#545)
a8b9697 feat(web): the serialisation contract — money as strings, values presentation-ready (#544)
d587bae fix(web): profit and loss were the same brightness, and inputs had no visible border (#543)

Verified structurally, not just from commit titles:

	v0.11.2 (what the site describes)	origin/main
keel/web/	__init__, render.py, security, server	__init__, api, events, payload, security, server, staticfiles, static/

render.py — the 872 lines of server-side HTML — is deleted on main. The architecture the site currently describes no longer exists upstream.

Why nothing changes on the site yet

The newest tag is still v0.11.2, and version in pyproject.toml on main is still 0.11.2. None of this has shipped to a single user, so under FR-9 it stays off the site.

The current copy remains accurate as written: install.ts browserTitle says "Work from the browser — shipped in v0.11.0", and v0.11.0 did ship that server-rendered browser app. It is a true statement about the released engine.

Do when the next release is cut

1. Rewrite browserTitle / browserBody in all three locales. The present copy describes credentials in the OS keychain, background market-data fetch, and attestations from a page. Re-verify every clause against the new keel/web/api.py + client shell — do not assume the rewrite preserved them.
2. Check whether the app is now installable (PWA). #551's title says "installable, with a worker that structurally cannot cache a balance". If true after release, that is a genuinely new user-facing capability and probably deserves its own copy, not a footnote.
3. Re-check features.ts — it claims capabilities with a "Verify in the repository" link per feature. Any link pointing into keel/web/render.py is now dead upstream.
4. Revisit the Python floor. 2d3934f raised it to 3.14 on main (see Install page: add keel's no-warning terminal installer (keel #479) #86 / feat(install): the one-command terminal path, and how to read it before you run it (#86) #88). At v0.11.2 the wheels still declare >=3.11. When a release ships with the new floor, the hero requirements string and the fromSource "any Python 3.11+" comment both go stale in the same moment.

Process note worth keeping

The install page pins its one-liner to raw.githubusercontent.com/.../main/scripts/install.sh. Because main moves, page copy describing that script can go stale without anyone touching this repo — that is exactly how the 3.11/3.14 error in #88 arose, and it was caught only because a reviewer fetched the live file instead of reading a local clone. Any future sync should git fetch keel first and read from origin/main, never from a working tree.