How the Target page and its assets render without a server

[stueydubs]

Question

Without a local server, how does the Target page render with its own relative CSS, fonts and images intact?

Today this is free: the server hands the browser the page and then answers every follow-up request the page makes, so <link href="../css/site.css"> and url(/fonts/x.woff2) resolve the way they do in production. A hosted app holding a directory handle has bytes, not URLs, and nothing answers the browser's follow-up requests unless webtweak makes something answer them.

This matters beyond fidelity. The Band picker reads the page's own media queries and the font list its own stacks, so a page whose stylesheet failed to load silently degrades the Overlay's controls rather than just looking wrong.

Resolve:

• The mechanism: a service worker synthesising responses from the directory handle, blob URLs, rewritten URLs, srcdoc, or something else. Name the choice and what it costs.
• How relative references resolve, and how root-absolute ones (/css/site.css) do. Root-absolute is the case --root exists to serve today, so it is known to be real in this audience.
• What happens to a reference that points outside the granted directory, whether by ../ or by symlink. The old server had realpath double-containment; state the replacement.
• Whether byte-transparent serving survives. The "Non-UTF-8 pages are served byte-for-byte" decision in CONTEXT.md exists because decoding and re-encoding destroyed the original bytes and poisoned every Fingerprint on a windows-1252 page. Whatever replaces the server must not reintroduce that.
• Whether Range requests can be synthesised. The current server supports them because Safari and iOS refuse to play media without them.
• Whether the page must be fetched fresh on every open or can be cached, and what invalidates that cache.

Blocked by #19, which establishes whether a service worker can serve from a directory handle at all.