encode: enforce the protobuf 2 GiB message-size limit

.changes/unreleased/breaking-changes-20260702-200419.yaml

@@ -0,0 +1,25 @@
+kind: Breaking changes
+body: |-
+    The u64 size-arithmetic discipline changes three public signatures:
+    `buffa::types::put_len_delimited_header` takes `len: u64` (was `u32`),
+    and `buffa::map_codec::field_len` / `message_field_len` take and return
+    `u64` (`MapCodec::encoded_len` and `FIXED_LEN` likewise — that trait is
+    sealed, so only the signatures are visible). Bare integer literals still
+    infer; a `u32` variable widens with `u64::from(...)`.
+    **Checked-in generated code must be regenerated**: code emitted by
+    earlier `buffa-codegen` versions passes `__cache.consume_next()` (a
+    `u32`) to `put_len_delimited_header` and adds `field_len` results into a
+    `u32` accumulator, so it fails to compile against this runtime. Regenerate
+    with your build pipeline (or `buffa-build`) after updating.
+    `ExtensionCodec` and `extension::codecs::SingularCodec` swap their
+    required encode method: `try_encode` / `try_encode_one` (fallible) are
+    now required, and the panicking `encode` / `encode_one` are provided
+    wrappers — so a codec whose encode can fail cannot accidentally leave
+    the fallible `try_set_extension` path panicking. All in-tree codecs are
+    updated; an external codec impl (if any exist) renames its method and
+    wraps the result in `Ok`.
+    Runtime behavior also changes: the existing encode entry points now
+    **panic** on messages whose encoded size exceeds the 2 GiB protobuf
+    limit — see the Fixed entry for the full list and the `try_encode*`
+    escape hatch.
+time: 2026-07-02T20:04:19.442227418Z

.changes/unreleased/fixed-20260702-174601.yaml

@@ -0,0 +1,26 @@
+kind: Fixed
+body: |-
+    **Encode now enforces the protobuf 2 GiB message-size limit.** Previously
+    encoding was infallible: a message whose encoded size crossed 2^31-1 bytes
+    serialized silently into a blob that no conforming decoder — including
+    buffa's own (`DecodeError::MessageTooLarge`) — would read back, and sizes
+    past 4 GiB wrapped `u32` arithmetic into corrupt output. Generated
+    `compute_size` now accumulates in `u64` and saturates at each node's return
+    (`buffa::saturate_size`), and every provided encode entry point on
+    `Message`, `ViewEncode`, generated lazy views, and `DynamicMessage` checks
+    the total against the new `buffa::MAX_MESSAGE_BYTES` constant.
+    **Behavior change:** the existing entry points (`encode`, `encode_to_vec`,
+    `encode_to_bytes`, `encode_length_delimited`, `encoded_len`,
+    `encode_with_cache`) now panic on over-limit messages (previously they
+    returned decoder-rejected or corrupt bytes); new `try_encode`,
+    `try_encode_with_cache`, `try_encoded_len`, `try_encode_length_delimited`,
+    `try_encode_to_vec`, and `try_encode_to_bytes` twins return
+    `Err(EncodeError::MessageTooLarge)` instead — `EncodeError` gains its first
+    variant. Fallible variants also cover the eager re-encode paths:
+    `ExtensionSet::try_set_extension` and `Any::try_pack` (message-typed
+    extension values and `Any::pack` encode their payload on the spot, so the
+    panicking originals document the new panic and these twins return the
+    error instead). In debug builds `SizeCache::consume_next` additionally
+    rejects over-limit slots as a backstop for callers driving
+    `compute_size`/`write_to` directly.
+time: 2026-07-02T17:46:01.12802197Z

SECURITY.md

@@ -6,12 +6,12 @@ Thank you for helping us keep this action and the systems they interact with sec
 
 This repository is maintained by [Anthropic](https://www.anthropic.com/).
 
-The security of our systems and user data is Anthropic’s top priority. We appreciate 
-the work of security researchers acting in good faith in identifying and reporting potential 
+The security of our systems and user data is Anthropic’s top priority. We appreciate
+the work of security researchers acting in good faith in identifying and reporting potential
 vulnerabilities.
 
-Our security program is managed on HackerOne and we ask that any validated vulnerability in 
-this functionality be reported through their 
+Our security program is managed on HackerOne and we ask that any validated vulnerability in
+this functionality be reported through their
 [submission form](https://hackerone.com/4f1f16ba-10d3-4d09-9ecc-c721aad90f24/embedded_submissions/new).
 
 ## Anthropic Bug Bounty