Constant MAX_RESPONSE_REBUFFER_BYTES 

pub const MAX_RESPONSE_REBUFFER_BYTES: usize = _; // 8_388_608usize

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.

Set to 4× DEFAULT_BODY_LIMIT_BYTES rather than reusing it outright: a create/update response that echoes the request payload plus server-added columns could legitimately land right at the request ceiling, so reusing the request-side number risks spurious failures on the response side. The 4× multiplier isn’t a bare guess either — it has an actual ceiling-on-the-ceiling to point to: crate::page::MAX_LIST_LIMIT (1000 rows) already bounds how large a list response’s item array can be, and crate::batch::BATCH_MAX_ITEMS-capped batch responses are similarly row-count-bounded, so a response several times the request ceiling comfortably covers realistic multi-row payloads without removing the ceiling altogether.

Exceeding this bound does not panic: every call site already matches on to_bytes’s Result and degrades to a synthesized CratestackError::Internal / error frame on Err, which is exactly what a LengthLimitError produces once the body is capped instead of unbounded.