README gets the per-model test run and the pod boot record; docs/runpod.md and
docs/remote-execution.md get the findings themselves, because each one cost a
live failure to learn:

- RunPod publishes no pod-log API. Checked against their OpenAPI spec: 23 routes,
  none for logs, and GraphQL refuses introspection. Code that "tried several
  routes" was guessing at URLs that never existed.
- The port appears only after the image is pulled, so the boot budget covers the
  download: 133s warm vs repeated failures at 300s cold, each one renting a fresh
  machine to pull the same image again.
- A machine may serve a cached ':latest', so a test against a floating tag cannot
  say which build it ran — pin a version when the answer has to mean something.
- Setting remotes.endpoints[capability] to test ONE model moves every request of
  that kind; that is how production embeddings ended up on a rented pod.
- Writing a config does not change routing until an idle engine takes the push,
  so a test must confirm the serving process has it before testing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY