fix(#346 review F1-F4): no 206-compress + Vary + precompress VAD + cache test

- F1 [HIGH — data corruption]: @fastify/compress was compressing 206/Range
  attachment responses while Content-Range still described the RAW offsets, so a
  resuming client (curl -C -, download managers) appended encoded bytes as raw →
  corrupted file. sendFileResponse now sets the request header `x-no-compression`
  (the documented @fastify/compress opt-out — its onSend skips when the request
  carries it; the reviewer's `Content-Encoding: identity` does NOT work because
  compress explicitly excludes `identity` and overwrites it). This opts the whole
  download route (both 200 full-file and 206 range) out of on-the-fly compression
  — correct, since attachment bytes are final and mostly binary.
- F2: static responses now emit `Vary: Accept-Encoding` (the preCompressed
  content-negotiated /assets/* were `immutable` without Vary → shared-cache could
  serve a brotli variant to an identity/gzip-only client).
- F3: vite compression `include` extended to .wasm/.onnx so the VAD binaries
  (~26MB .wasm, ~2.3MB .onnx under public/vad) are precompressed at build (.br
  emitted) instead of runtime-brotli'd on every request. (include REPLACES the
  plugin default, so the default js/css/json/html set is re-listed.)
- F4: extracted the cache classification into a pure `resolveStaticAssetHeaders`
  + static.module.spec.ts (3 tests: /assets/* immutable+Vary, index.html
  no-store, non-hashed not-immutable).

Gate: server tsc 0 (deps present), static.module.spec 3/3, client build emits
.wasm.br/.onnx.br, frozen install 0.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

apps/server/src/core/attachment/attachment.controller.ts

@@ -474,6 +474,19 @@ export class AttachmentController {
     const fileSize = Number(attachment.fileSize);
     const rangeHeader = req.headers.range;
 
+    // Opt this download route out of the global @fastify/compress hook.
+    // Attachment bytes are final and mostly binary, so on-the-fly compression
+    // only burns CPU — and on the 206/Range branch it is actively corrupting:
+    // compress decides purely by Content-Type, so for a compressible mime
+    // (application/octet-stream fallback, image/svg+xml, text/*) it would gzip
+    // the byte slice and drop Content-Length while Content-Range still
+    // describes the RAW offsets and the status stays 206. A resuming client
+    // (`curl -C -`, download managers) then appends the encoded bytes as if
+    // raw and ends up with a broken file. @fastify/compress skips whenever the
+    // request carries `x-no-compression` (see its onSend hook), so setting it
+    // here covers both the 200 (full file) and 206 (range) responses.
+    req.headers['x-no-compression'] = 'true';
+
     res.header('Accept-Ranges', 'bytes');
     res.header(
       'Content-Security-Policy',