feat(homepage): update the talk tile to the inverted mark

talk shipped a reworked mark at v18 on operator ruling — the 1024x1024
cerulean field rect is gone, the bubble now carries #03adfb where it used to
carry #2e2d30, and the three waveform bars are holes rather than filled
shapes. Path data is byte-identical to the original trace; only the two fills
moved. Fetched from the app and from the booth and confirmed the two sources
are byte-identical before taking either.

tts-dev flagged a real risk with the change: with the field gone the tile
background shows THROUGH the waveform holes, so a tile close to #03adfb would
swallow the bars. Checked rather than assumed. Homepage's card surface is
--sea-20, oklch(0.31 0.022 262) = #2a313c, a dark desaturated navy; the bubble
against it is 5.22:1, well clear of the 3:1 bar for non-text graphics. The
page ground behind it is 6.73:1. Safe on this tile specifically — the earlier
"reads well against the tile background" judgement was about a solid square
and did not carry over on its own.

Also refines the Next.js note in CLAUDE.md, which was over-broad. A NEW file in
the images mount 404s until restart, but REPLACING an existing file's bytes
serves immediately with no restart — measured here, the served hash matched the
new file straight after rsync. It is the route table that freezes at container
start, not the file contents. The previous wording would have had people
bouncing Homepage for every icon tweak.

CLAUDE.md

@@ -227,10 +227,13 @@ Observed and standardized across servers:
   served at `/images/<file>`), NOT in the config dir.** Homepage v2 serves only
   `custom.css` / `custom.js` out of `/app/config`, so `conf/icons/foo.svg` 404s
   even though the file is plainly there in the container. ⚠ **And Next.js builds
-  its `public/` route manifest at container START** — a file dropped into the
-  mounted images dir 404s until you `docker restart homepage`, while files that
-  predate the start serve fine. That asymmetry reads exactly like a bad mount or
-  a permissions problem and is neither. Reference it as `icon: /images/<file>`.
+  its `public/` route manifest at container START** — a NEW file dropped into
+  the mounted images dir 404s until you `docker restart homepage`, while files
+  that predate the start serve fine. That asymmetry reads exactly like a bad
+  mount or a permissions problem and is neither. **Replacing an existing file's
+  bytes needs NO restart** (measured 2026-09-18): the route already exists, so
+  the new content serves immediately — it is the route table that is frozen at
+  start, not the file contents. Reference it as `icon: /images/<file>`.
 - **Healthchecks** on services that expose HTTP
 
 ## Servers