Find which limit you hit first as load grows

Find what runs out first as load grows.

Produce:
1. Per resource — CPU, memory, disk, IOPS, network, connection pools, file descriptors, thread pools, external API quotas, license seats — **headroom expressed as a multiple of current load.**
2. Ranked by which is reached first. *The first ceiling is the only one that matters until it is raised.*
3. For each of the top three: what the failure looks like when it is reached. Some degrade gracefully and some fall over, and the difference changes the priority.
4. **Non-linear limits** — things that do not scale smoothly: connection pool exhaustion, a lock that serializes, a single-writer component, a cache that stops fitting in memory and collapses. These arrive suddenly and are missed by linear projection.
5. What to measure that I am not measuring, where headroom is unknown.

Then: the order to raise ceilings, and which are quick versus which need re-architecture.

Rules:
- *Do not project linearly through a known non-linear limit.* Say when the model breaks down.
- Where I did not give a number, say the headroom is unknown rather than assuming it is fine.
- Note ceilings that are external and cannot be raised by adding hardware — third-party rate limits, provider quotas.