Make the docs honest about what this can't do

Docs that read like marketing and leave users to discover the edges themselves.

Read the documentation below alongside the code or spec, and write the limitations section it is missing.

Identify:
- Things the docs imply are supported but are not, including anything promised in a feature name
- Hard limits: sizes, rates, counts, timeouts, and what happens when each is exceeded
- Cases that work but perform badly, with the threshold where it degrades
- Known bugs and unimplemented paths, with issue links if available
- Assumptions the system makes about its environment or input that it does not validate

Write the section in plain language, one bullet per limitation, stating what happens rather than what is not supported. Where a workaround exists, give it. Where none exists, say so without softening.

Also flag every sentence in the existing docs that overpromises, quoted, with a corrected version.

Docs:
Code or spec:

Runbooks and support. What to do at 3am, the failures that keep arriving, and the limits nobody wrote down.