Config: reject a too-small max_body_bytes, not only zero

Summary

Config resolution rejects a zero max_body_bytes (and a zero count_quota), because a zero cap would silently brick all writes. But it accepts any positive value, including ones far too small to admit a viable request body — e.g. max_body_bytes = 10. Such a value bricks writes just as completely as zero, with no diagnostic, yet passes validation. This issue tracks adding a sane lower floor.

Detail

The zero-rejection at config resolution closes the most obvious footgun, but the underlying hazard is "a body cap so small no real write fits," and zero is only the extreme case of it. A deployer who fat-fingers max_body_bytes to a tiny value (or expresses it in the wrong unit) gets a server that boots cleanly and then refuses every write with a size error — the same silent-brick failure the zero-rejection was added to prevent.

What "done" looks like

Reject, at config resolution with a clear error, any max_body_bytes below a defensible minimum viable request-body size (the floor should be derived from the smallest well-formed write the server can accept, not an arbitrary constant). The error should name the configured value and the floor. Consider the same reasoning for other [limits] values whose small-but-nonzero settings are effectively degenerate.

Note

Deciding the exact floor needs a little deliberation (what is the smallest legitimate write?), which is why it was deferred rather than patched with a reflexive constant.

Start at config resolution and trace the smallest well-formed write the server accepts to derive a defensible minimum for max_body_bytes. Review the other [limits] values for similarly degenerate settings; done means undersized values are rejected with an error naming both the configured value and the derived floor.