Audited all 66 /v1 endpoints against the capability map. One was
unmapped: /v1/audio/progress, so polling an audio job would be answered
locally while the job ran on the remote — always empty. Mapped to
audio_gen, and a test now asserts the whole set, so a newly added
endpoint cannot quietly stay local.

The bigger hole was results. With the default response_format "url" a
render answers with a URL built from the REMOTE's base
(http://pod-xyz:8000/v1/files/out.png): unreachable from the client, and
a 404 if fetched here because the file is on the pod. The gateway now
rewrites those URLs to this instance and remembers which remote produced
each file, so GET /v1/files/<name> follows back to it. Only JSON bodies
are buffered for the rewrite; everything else still streams untouched.

The map is a bounded routing hint (newest 4096), not a store: a pod
reaped for idleness takes its outputs with it, so fetch what you need or
ask for b64_json. Documented.

Admin, /internal, /chat, /login and /healthz stay local by design —
they administer or identify THIS instance.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY