dict — compression dictionary lint

  Compression dictionaries fail silently. Chromium declines to register a
  perfectly good one because of a cache directive on it, and nothing tells
  you: no console warning, no header, no failed request. Your site just serves
  full responses forever while you believe it is serving deltas.

    curl 'aadhar.sh/dict?url=https://example.com/app.js'

  ── what it checks ──────────────────────────────────────────────────────────
  The rules that decide registration, applied to the response headers of the
  resource you point it at, plus the other half of the handshake: whether a
  delta-serving response varies on available-dictionary. A cache that does not
  is not a slow page, it is ERR_CONTENT_DECODING_FAILED.

  ── measured on this origin ─────────────────────────────────────────────────
  shell assets (js/css)     93-97% off, per-asset dictionaries
  pages, family corpus      ~26% off q11 (298,933 B vs 405,909 B across 38 pa…
  a dictionary 11 days stalestill 87-93% — freshness matters far less than pe…
  dcz vs dcb, size          dcb wins by ~6.8% across 12 pairs
  dcz vs dcb, decode        dcz 0.0165ms vs brotli 0.1368ms on a 47KB rebuild…
  why dcz anyway            decode scales with the REBUILD, not the delta, so…
  zstd level 19 vs 22       byte-identical on every asset here; above 19 is d…

  There is deliberately no delta calculator here. workerd's node:zlib has
  zstdCompressSync and SILENTLY IGNORES its dictionary option — measured
  2026-08-05, identical byte counts with the right dictionary, a wrong one,
  and none. A delta computed here would be plain zstd reporting a saving that
  does not exist.

  &url= audit a resource