[audit][high] Unchecked size arithmetic can undercount storage costs

[QuantumExplorer]

Created from a Codex audit of grovedb. No code changes were made as part of the audit.

Summary

Several element sizing and cost-accounting paths use unchecked u32 arithmetic or unchecked casts.

Impact / failure scenario

Near-u32::MAX lengths can wrap in release or panic in debug, causing undercharged storage costs or verifier bypasses.

References

• grovedb-element/src/element/helpers.rs:622
• grovedb-element/src/element/helpers.rs:647
• grovedb-element/src/element/helpers.rs:681
• costs/src/lib.rs:194
• costs/src/storage_cost/key_value_cost.rs:64
• grovedb/src/batch/mod.rs:2945

Suggested fix

Use checked_add, checked_sub, and u32::try_from with explicit overflow errors.

Suggested tests

Add boundary tests around u32::MAX, u32::MAX - n, and oversized serialized values.

[QuantumExplorer]

Closing after adversarial verification: not a reachable bug. All the cited sites do use unchecked u32 arithmetic, but overflow requires a single length approaching 4 GiB, which cannot occur: key-side overflow is impossible because merk's link encoding caps key length at a single byte (≤255), and value-side overflow would require a ~4 GiB serialized element — orders of magnitude beyond platform's state-transition and document size caps. Computed costs are bit-identical for every input that can actually exist, so there is no undercounting in practice. The associated PR #737 (checked arithmetic returning Overflow errors) is harmless hygiene — bit-identical for all real inputs — and can be merged or closed on its own merits, but the underlying finding is not a real issue.