Fetch every section in one query instead of one per…

Details

Each layout walks its own `[data-db-section]` shells and the publication list
asks for its own, so `sections_public` went out once per section — six times on
`/` and `/v2/`, each carrying its own CORS preflight because `apikey` and
`Authorization` are not simple headers.
PostgREST takes `section=in.(a,b,c)`. The batch is collected synchronously and
flushed on the microtask queue, so everything that asks before the first await
rides along; a caller that arrives later opens the next batch rather than
joining one that has already been sent. Callers are unchanged —
`fetchSectionItems(name)` keeps its signature and its per-section
sessionStorage cache, and a requested section with no rows now caches as empty
instead of being re-requested for the rest of the session.
Measured at 1440 on a real build, Supabase responses and wire bytes per cold
page load:
  /      20 -> 12 responses   21.6 -> 19.7 KiB   (sections 12 -> 4)
  /v2/   10 ->  6 responses   21.6 -> 17.0 KiB   (sections  6 -> 2)
`/` still shows two batches because the publication list asks a tick after the
section shells; `/v2/` collapses to one.
Content verified unchanged: all five section shells hydrate on `/`, all six on
`/v2/`, and the 27 publication links still resolve. Retry after forced 500s
still recovers (9 publications, 126 asset keys) with no unhandled rejection.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DAJJ63FFnLoD5XLpu6yJaG

Files changed (1)