record that RunPod should be one provider of several, not the only one

Scaleway, Exoscale, OVHcloud and Hyperstack all rent GPUs by the hour or the
second, and nothing about the fleet logic is really RunPod-shaped. Written
down now so the seam does not have to be re-derived later; none of it is
built.

The point worth keeping: the provider-specific part is small. Demand-based
growth, the reaper, budgets, the ledger, spillover, shared pools, LoRA
fan-out and region selection all sit above the provider and ask it for about
eight things, which RunpodClient already is -- ping, a catalogue with VRAM
and price, create, get/list, wait_ready, stop/terminate, logs, volumes. A
second provider is a second client plus a per-pool choice, not a second
orchestrator.

The section also lists what will NOT port, because the §10 notes were all
found live and most are categories rather than one provider's quirk: an
undocumented image size ceiling, a boot budget that has to cover the image
pull, how the port is reached (proxy vs direct TCP vs a load balancer with
its own idle timeout), rate limits in their own units, terminal states that
do not look terminal, and region-scoped storage.

Indexed from docs/README.md so it is findable without reading to the end of
an 890-line file.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC