Reverts the advice in 8b976170, which was wrong. A pod serving ~32 pages
at once is a fact about what the SERVER should dispatch to one pod, not
about what the CLIENT should offer. Offering only what the pods can hold
means that the instant a page finishes there is nothing queued to replace
it, so every pod idles for a round trip between every page -- losing
exactly the throughput the queue exists to protect.

The split is now explicit in the guide: the client offers 64 x pods, the
server dispatches ~32 to each pod (discovered from the pod, v0.4.38) and
holds the rest queued and ready. The client cannot overload a pod by
offering more, and does not need to track what a pod can take.

Admission is sized for exactly that offer: 4096 dispatched + 4096 queued
= 64 x 128 pods, with 429 only beyond it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM