perf(build): replace adapter precompress with a parallel, filtered step

adapter-node's `precompress: true` brotli-q11 + gzips every file in
build/client single-threaded — ~150 MB including 91 MB of already-
compressed media (zero gain) and tens of MB of server-only data — adding
minutes to the build. The worst offenders were ML embedding JSONs
(nutrition 35 MB + bls 20 MB + shopping ~4 MB) that are `?url`-imported by
$lib/server/{nutritionMatcher,shoppingCategorizer}.ts and read server-side
via SvelteKit's read(); no browser ever fetches them, so compressing them
is pure waste.

- svelte.config.js: precompress: false.
- scripts/precompress.ts: postbuild step that only compresses text asset
  types, skips binaries and server-only data (bible TSVs by name, embedding
  JSONs by hashed-name pattern), tunes brotli quality down for large files,
  runs gzip+brotli in parallel, and never writes a larger-than-original or
  duplicate sibling.
- package.json: run precompress after build-error-page with
  UV_THREADPOOL_SIZE=12 so the async compression actually parallelizes.
- Delete static/allioli.json: 20 MB, unreferenced anywhere in the repo.

svelte.config.js

@@ -19,7 +19,12 @@ const config = {
 		// If your environment is not supported or you settled on a specific environment, switch out the adapter.
 		// See https://kit.svelte.dev/docs/adapters for more information about adapters.
 		adapter: adapter({
-			precompress: true  // Enable brotli and gzip compression
+			// Precompression is handled by scripts/precompress.ts in postbuild.
+			// The adapter's own precompress is single-threaded and brotli-q11s every
+			// file in build/client — including ~90 MB of already-compressed media and
+			// 20 MB+ text blobs — adding minutes to the build for no gain. Our step is
+			// parallel, skips binaries, and tunes brotli quality by size.
+			precompress: false
 		}),
 		prerender: {
 			// The only intentionally-static pages are /hikes (prerender=true) and