The Models page fired ~10 /admin/api reads on load. Browsers cap ~6 connections
per host, so during a generation (engine event loop GIL-busy) the proxied reads
pile up, saturate the limit and freeze the whole page behind them.

Two fixes:

1. New front endpoint POST /admin/api/batch: fans out several engine GET reads
   CONCURRENTLY server-side (front's own un-capped pool), each individually
   bounded, and returns them in one response. A slow/blocked sub-call returns an
   error marker without holding up the rest. base.html gains bootstrapPage() +
   pageFetch(): the page batch-loads its first-paint reads in ONE request, and the
   existing loaders transparently serve from the bundle (falling back to a normal
   fetch on miss). models.html now collapses settings/cache-stats/cached-models/
   models/quantize-status/downloads into a single batched call, plus an in-flight
   guard on the downloads poller so ticks can't stack up.

2. Bound /admin/api/* GET proxying (catch-all) with a finite read timeout +
   graceful 503 fallback, so a busy engine can never hang a page forever (HF hub
   lookups and streaming endpoints keep the unbounded path).

Verified: batch unit test (concurrent aggregation, error markers, path filtering,
auth) and node syntax-check of the bootstrap script.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011DDv7BchtZQWsnPG6Jm49m