docs: fix slow docs-site search and restore compression

The new client-side search shipped a 1.46MB search_index.json, which
froze the search box for seconds on the first keystroke (#6654). Two
separate causes: a pre-existing bug disabled compression site-wide
(made painful only once search added a large asset), and the index was
fetched and built on the main thread. Fixes, each independent:

1. Re-enable compression (main.py): stop copying the blob's
   content_encoding onto the response. It falsely marked plain bodies as
   gzip, which made App Engine skip its own compression for every asset.
   Removing it takes search_index.json from 1,455,885 -> ~531KB (2.7x)
   and shrinks all JS/CSS/HTML too (e.g. script.js 30KB -> 12KB).

2. Store the index gzipped and typed (deploy, mime_util/file): add json
   to the rsync -j list and map .json -> application/json (was defaulting
   to text/html).

3. Build the index in a web worker (script.js, search_worker.js):
   tokenizing ~1.2MB of text took seconds on some browsers and froze the
   page. Moving fetch + build + ranking into a worker keeps the main
   thread responsive (measured main-thread stall dropped from ~5s to
   ~17ms); script.js only sends the query and renders the results posted
   back. Warm queries return in ~125ms (just the debounce). The download
   is unchanged at ~531KB. Follows the worker pattern already used for
   the trace_processor engine in ui/.

4. Warm and show progress (script.js, style.scss): spawn the worker at
   idle so the index is usually built before the first search, and show
   a loading row if the user types before it's ready, instead of a
   frozen box.

5. Cache the index for an hour (main.py): was 10 min; avoids re-fetching
   ~0.5MB on every page navigation during a reading session.

Also bumps the App Engine runtime python38 -> python313, which is
unrelated but required as python38 is no longer accepted for deploys.