swarm-ui: content-hash main/theme/swarm-ui-css filenames for real cache-busting

Every redeploy currently changes the nix store path serving swarm-ui's
JS/CSS but never the URL the browser requested (main.js, main.css,
theme.css, swarm-ui.css are all fixed filenames) -- so a browser can get
stuck serving yesterday's bundle after a deploy until someone clears the
cache by hand.

build.mjs now hashes main.tsx's JS bundle + its companion CSS output,
plus theme.css and swarm-ui.css, via esbuild's own metafile (not a
guessed hash algorithm), and rewrites the real URLs into index.html and
sw.js after the build.

colors.css deliberately stays unhashed: nix/host-modules/swarm-ui.nix's
stylix theming swaps that exact fixed path via an `= /static/colors.css`
nginx location override with no npm/esbuild rebuild involved. Hashing it
would silently break that swap on a themed host.

sw.js's CACHE_VERSION is now derived from the real hashed URLs instead of
a hand-bumped literal, so any shell-asset change gets a fresh cache name
and the SW's own activate-time sweep evicts the previous one in full --
fulfilling a promise its own prior comment already made.

Scope: swarm-ui only, per mara's call on hyperhive#4283 ("this is about
swarm ui - everything else will eventually migrate over"). dashboard and
agent are untouched.

frontend/packages/swarm-ui/src/sw.js

@@ -7,26 +7,27 @@
 // a cached fetch would be worse than showing nothing (mara: "scope looks
 // good" — approving that as a hard rule, not a short-TTL middle ground).
 //
-// Network-first for the shell, not cache-first: `main.js`/`main.css` are
-// unhashed filenames, so a cache-first strategy would risk wedging an
-// operator on yesterday's JS after a deploy until they manually cleared
-// it (a deploy changes the nix store path serving these but not the URL
-// the browser cached against — a separate, already-filed fix). This SW
-// only ever serves its cache on a FAILED fetch (offline/flaky network),
-// never in preference to a successful network response.
+// Network-first for the shell, not cache-first: most assets below are
+// content-hashed (a fresh URL per deploy, so a normal visit always gets
+// the current bundle regardless of this SW), but `colors.css` stays
+// deliberately unhashed for the host-side stylix theme swap, so this
+// SW's own cached copy of it can only ever refresh via a real network
+// round-trip. This SW only ever serves its cache on a FAILED fetch
+// (offline/flaky network), never in preference to a live response.
 //
 // Plain JS, not TypeScript, deliberately — the DOM lib swarm-ui's own
-// tsconfig uses and the WebWorker lib a service worker's globals
-// (`self`, `ExtendableEvent`, `FetchEvent`, `caches`, ...) need are
-// mutually exclusive in one tsc program, and this file is small/
-// self-contained enough that a second tsconfig just to typecheck it
-// isn't worth the config surface. Same treatment `build.mjs` already
-// gets in this package.
+// tsconfig uses and the WebWorker lib a service worker's globals need
+// (`self`, `ExtendableEvent`, `FetchEvent`, `caches`, ...) are mutually
+// exclusive in one tsc program, and this file is small enough that a
+// second tsconfig just to typecheck it isn't worth the config surface.
+// Same treatment `build.mjs` already gets in this package.
 //
-// CACHE_VERSION is bumped by hand for now — once the filenames above are
-// content-hashed, the cache name can derive from the build itself and
-// this manual step goes away.
-const CACHE_VERSION = "v1";
+// CACHE_VERSION is filled in by build.mjs from a hash of every hashed
+// shell-asset URL below, so any real content change gets a fresh cache
+// name and `activate`'s old-cache sweep evicts the previous one in
+// full. This literal placeholder is never served; the build always
+// replaces it.
+const CACHE_VERSION = "__BUILD_VERSION__";
 const CACHE_NAME = `swarm-ui-shell-${CACHE_VERSION}`;
 
 // Every navigation (any client-side route wouter handles — /agents,