[audit][medium] Storage removal addition drops default-section removals

[QuantumExplorer]

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

Summary

Combining basic and sectioned storage removals removes/updates the default identifier entry but does not reinsert it.

Impact / failure scenario

Removal bytes from the default identifier can be lost, undercounting storage removals and any costs derived from them.

References

• costs/src/storage_cost/removal.rs:83
• costs/src/storage_cost/removal.rs:102
• costs/src/storage_cost/removal.rs:148

Suggested fix

Reinsert the updated default epoch map before returning or assigning the combined SectionedStorageRemoval.

Suggested tests

Assert Basic + Sectioned(default), Sectioned(default) + Basic, and AddAssign all preserve both removal amounts.

[QuantumExplorer]

Re-rating high → medium after adversarial verification. Confirmed real and the most significant finding of this audit batch: three of the four Add/AddAssign arms combining BasicStorageRemoval with SectionedStorageRemoval drop the entire default-identifier section plus the basic bytes being folded in, and the path is reachable from Drive execution (default-identifier StorageFlags sections and basic-removal fallbacks accumulate into the same pending cost). Not high, because the error is deterministic across all nodes — identical undercounted refunds everywhere — so there is no divergence, halt, or credit inflation; the impact is users being under-refunded. The fix (#726, version-gated to GROVE_V3 with legacy semantics preserved for replay) should land before the 4.0 protocol version freezes, since fixing it afterward requires a GROVE_V4 bump and bakes the wrong refunds into mainnet history for the 4.0 era.