THE SURYA BUG. `/v1/ocr/attach/<lease>/…` is an OCR engine attaching to THIS
install's gateway. The lease is minted here and lives in this process's memory
— and the remote gateway was FORWARDING those requests to the pod, which
correctly refused a token it never issued:

    404 {"error": {"message": "unknown OCR engine lease"}}

surya's client swallows that and returns an empty generation, so every page
came back unread with the GPU never asked to read one. Measured on a clean
2-page PDF that chandra (2212 chars) and olmOCR (1992) both read: surya
returned 2 characters, and the pod's vLLM logged a single 6-token warm-up for
the whole document. $88 of surya time in one day produced nothing.

The gateway behind that prefix does its OWN forwarding, with its own pool and
its own lease. That is the hop, and it has to start here. `/v1/ocr` itself
stays routable, so pinning the attachment does not strand the subsystem.

This also corrects an earlier diagnosis of mine: v0.3.87 treated this as a
lease VOIDED BY A RESTART and shipped a re-resolve for it. No restart was
involved — the lease was wrong from the first page, which is why surya has
been broken continuously rather than only after restarts. That work was not
wasted (the retry cap took four paid generations per page down to two, and the
502 plus `unread_pages` are what made this diagnosable at all) but it did not
address the cause.

Third instance today of one mistake: the gateway forwards anything under /v1/
that looks like a model request, including this install's own control plane.
/v1/runpod rented a pod to deliver a teardown; /v1/loras was staying local by
luck; now the OCR lease. All three are pinned. The structural answer — making
control-plane routes opt IN to forwarding — is not in this commit.

Also in here, from the fleet-hygiene pass:

  * accelerate added to every profile that carries transformers (audio, ocr,
    stt, tts, voice, tts-xtts.venv-TTS), with a test that fails if a new
    profile reintroduces the gap. Same latent fault that broke embeddings.
  * an embeddings pod is warmed on /v1/embeddings, not with a chat completion
    it refuses by design — that 404 was printed on every boot of a healthy pod
    and cost a wrong diagnosis.
  * the seed plan is announced once, not every fifteen seconds while a pod
    boots, so a boot log stays readable when it matters.
  * `pool:` is dropped from pod NAMES (ownership is the prefix, never the rest).
  * the reaper owns a pod by REGISTRY as well as by name, so renaming
    deployment_id no longer orphans pods that are already running and billing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM