When wiring ABCI state-sync, cap incoming snapshot-chunk message size before grovedb decode

Filed by Claude (AI-generated) as a forward-looking tracking item — no live bug today.

Context

GroveDB's consensus replication / state-sync API (GroveDb::apply_chunk, start_snapshot_syncing, MultiStateSyncInfo) decodes peer-supplied packed buffers via unpack_nested_bytes. A grovedb audit finding (dashpay/grovedb#696) flagged that this decoder "lacks resource caps." On review the decoder itself is safe — it is linear-bounded by its input (count capped at (len-4)/4 before allocation, per-element lengths validated with checked_add + a 32-bit truncation guard, trailing bytes rejected), so there is no amplification attack. grovedb#696 is being closed as by-design, with the documentation pointing callers at the size-cap responsibility (dashpay/grovedb#754).

There is no live attack surface today: rs-drive-abci does not implement the ABCI snapshot handlers (apply_snapshot_chunk, offer_snapshot, load_snapshot_chunk, list_snapshots) — they remain default no-ops in rs-tenderdash-abci — so no peer bytes currently reach grovedb's decoder via the consensus path.

The actionable item (for whenever ABCI state-sync is implemented)

When the ABCI apply_snapshot_chunk handler is implemented in rs-drive-abci and wired to GroveDb::apply_chunk, the handler must enforce an absolute packed-message-size cap on untrusted peer data before handing it to grovedb's decoder.

Notes:

rs-tenderdash-abci's server codec (abci/src/server/codec.rs) imposes no max message-size of its own — it reads a length-delimited frame of whatever size is declared. So the Rust transport layer does not provide this bound for free.
The effective upstream bound, if any, comes from Tenderdash's (Go) state-sync chunk-size limits. Either rely on that explicitly (and document/verify it) or add a defensive cap at the Drive ABCI handler boundary.
This is defense-in-depth against a malicious/buggy peer forcing large (though still O(input)) allocations during state sync; severity is low and contingent on the feature being built.