Module limits 

Cross-cutting request/response size ceilings for the generated Axum surface (cratestack#413). Lives in its own module rather than being appended to page.rs/batch.rs: those two already own their own numeric ceiling (MAX_LIST_LIMIT, BATCH_MAX_ITEMS) scoped to their own concern, so a body/response-size constant that cuts across both REST and RPC belongs in a module of its own — see docs/design/request-response-size-bounds.md (Reviewer notes) for the reasoning.

Both constants below are threaded through the generated router() / rpc_router() entry points as an explicit body_limit_bytes: usize parameter, not applied as a fixed .layer(...) a consumer is expected to re-layer on top of. That’s a deliberate, empirically-verified choice, not an oversight: axum::extract::DefaultBodyLimit is extension-based, and DefaultBodyLimitService::call unconditionally overwrites that extension on every invocation with no “already set” check. Because a consumer can only ever wrap a Router cratestack has already returned — never insert a layer between cratestack’s own layer and the handler — whichever DefaultBodyLimit sits closest to the handler always wins, and that’s structurally always cratestack’s, regardless of whether the consumer’s re-layered value is larger, smaller, or a disable(). See docs/design/request-response-size-bounds.md Decision 2 for the reproduction. A real constructor parameter has no such failure mode: exactly one DefaultBodyLimit layer is ever constructed, with the caller’s chosen value baked in once.

Constants

DEFAULT_BODY_LIMIT_BYTES

Default request body limit (bytes) for the generated router() / rpc_router() entry points, applied via axum::extract::DefaultBodyLimit::max(body_limit_bytes).

MAX_RESPONSE_REBUFFER_BYTES

Bound used at every axum::body::to_bytes(body, N) call site that re-buffers a Response produced in-process (RPC batch per-frame re-encoding, handler-error re-shaping, and the per-frame codec round-trip helper — see crates/cratestack-axum/src/rpc/{batch,error_encode, codec_helpers}.rs). None of these three sites face an untrusted upstream/proxied body; all buffer a response cratestack itself produced, so this is a safety valve against a pathological in-process response (e.g. a handler bug or a legitimately huge result set), never a network-trust boundary the way DEFAULT_BODY_LIMIT_BYTES is.