encode: enforce the protobuf 2 GiB message-size limit

[rpb-ant]

Encoding was infallible while decode has always rejected length-delimited payloads over 2 GiB−1 (DecodeError::MessageTooLarge): a writer whose message crossed 2^31−1 bytes silently serialized a blob that no conforming decoder (including buffa's own) will read back, and past u32::MAX the size arithmetic wrapped outright, producing corrupt output. In production the failure surfaces far from the cause — the writer keeps succeeding while every reader starts failing. buffa now refuses to produce bytes it wouldn't accept.

Design

"Wide inside, checked at the door" (protobuf C++'s shape: size_t ByteSizeLong() + an INT_MAX check at the serialize entry):

• Generated compute_size accumulates in a u64 local (which can't overflow for any in-memory message) and saturates to u32 once at each node's return (buffa::saturate_size). The trait signature and SizeCache stay u32; the 2–4 GiB window stays byte-exact so the guard sees true values.
• compute_size is bottom-up and monotone, so one check at the top-level entry points provably catches aggregation overflow, sub-message overflow, and the single-huge-field case. Existing entry points (encode, encode_to_vec, encode_to_bytes, encode_length_delimited, encoded_len, encode_with_cache) panic before writing anything; try_* twins return Err(EncodeError::MessageTooLarge), the first variant of the previously uninhabited enum.
• The same rule applies everywhere size arithmetic lives: write_to's transient packed/map lengths, the map_codec runtime helpers, lazy-fragment sizing, DynamicMessage (usize-exact, own guard), SizeCachePool. A codegen test locks the rule by asserting emitted compute_size/write_to bodies contain no u32 arithmetic.
• Belts: a debug-build assertion that write_to produced exactly the byte count compute_size declared (the write pass is wrap-free ground truth, so this converts future two-pass codegen bugs into CI failures), and SizeCache::consume_next rejects over-limit slots for callers driving the two passes directly.
• Internal Result-returning pipelines that re-encode parsed messages (JSON/text Any and extension converters, pack_any, to_message, from_options) surface the condition through their existing error channels rather than panicking.

Structure

Four commits: (1) runtime guard + try_* surface on Message/ViewEncode/SizeCachePool; (2) u64 size arithmetic in codegen + map_codec + lazy views, with regenerated WKT/descriptor code and the codegen lock test; (3) DynamicMessage + fallible-pipeline migrations; (4) logging-example regen (which surfaced pre-existing buffa::Map drift in its main.rs) and a SECURITY.md markdownlint fix.

Notes for review

• Behavior change, called out in the changelog fragment: over-limit messages now panic at the existing entry points instead of producing decoder-rejected/corrupt bytes. The panic message names the try_* escape. prost has no encode cap at all; protobuf C++ and Go both error here.
• put_len_delimited_header now takes len: u64 (was u32) — bare literals still infer; u32 callers widen with u64::from.
• encoded_len() panics rather than returning a saturated lie; try_encoded_len() is the non-panicking probe.
• The reflection codec's usize sizing is exact on 64-bit; the 32-bit theoretical wrap (shared Bytes clones summing past usize::MAX) is documented in-code and unreachable in practice.
• examples/bsr-quickstart remains stale (regen requires BSR auth), same as on main.

Verified: full workspace tests, clippy -D warnings, no_std (host + thumbv7em) and MSRV 1.75 checks, conformance 14/14, and a consumer-crate drive: a version-envelope message at exactly 2 GiB−1 encodes and decodes back; one byte over returns Err(MessageTooLarge) with nothing written (not even the length prefix); encode_to_vec panics with the documented message; a 4.4 GB payload (the old u32-wrap class) errors instead of wrapping.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}