fix(cli): serve the embedded web UI brotli-compressed

[Hona]

The server's HttpMiddleware.compression() already brotli-compresses responses, but for embedded assets that meant two steps on every request: decompress the archive's brotli body, then compress it again at the middleware's level 4. Fonts weren't compressed at all, because font/ttf isn't on the middleware's compressible list. Now a browser that accepts br gets the archive's quality-11 bytes as they are.

flowchart LR
  subgraph Before
    A[embedded br q11] -->|decompress| B[raw asset] -->|"compress br q4<br/>(fonts: none)"| C[browser]
  end
  subgraph After
    D[embedded br q11] -->|"Content-Encoding: br"| E[browser]
  end

Loading

Loading every web UI asset (1,691 files) from the Windows x64 CLI with Accept-Encoding: gzip, deflate, br:

	Before (#53644)	This PR
JS, CSS, HTML sent	7.8 MB	6.5 MB
Fonts sent	17.9 MB	8.3 MB
WASM sent	12.0 MB	8.7 MB
Total sent	38.2 MB	23.9 MB
Time to serve all	1.7 s	0.3 s
CLI / desktop installer size	203.8 / 241.4 MB	203.8 / 241.4 MB

• index.html is still sent decoded, because its CSP hashes the inline theme script. The middleware compresses it as before.
• A client that doesn't accept br, or sends br;q=0, still gets decoded bytes. The middleware leaves any response that already has a Content-Encoding untouched.
• Both kinds of asset response carry Vary: accept-encoding.

const encoded = key !== "index.html" && acceptsBrotli(request.headers["accept-encoding"]) ? brotli?.[key] : undefined
const requested = encoded ?? assets[key]

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.