[audit][medium] Non-empty tree delete can reopen parent with child tree type

[QuantumExplorer]

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

Summary

Direct delete of a non-empty child tree can reopen the parent path using the child tree’s tree_type.

Impact / failure scenario

Deleting under CountTree/sum/count-sum parents with allow_deleting_non_empty_trees=true can propagate aggregate/root metadata incorrectly.

References

• grovedb/src/operations/delete/mod.rs:740
• grovedb/src/operations/delete/mod.rs:750
• grovedb/src/operations/delete/mod.rs:847
• grovedb/src/operations/delete/mod.rs:880

Suggested fix

Reopen with the parent’s saved tree type or reuse the already-open parent subtree handle.

Suggested tests

Delete a non-empty child under an aggregate parent, then verify aggregate count/sum and verify_grovedb.

[QuantumExplorer]

Re-rating high → medium after adversarial verification. The bug is real — deleting a non-empty subtree reopens the parent Merk with the child's tree type, and a verify_grovedb hash mismatch was empirically reproduced with a ProvableCountTree parent on the legacy path (real state corruption, not just cost skew). Not high, because the path is unreachable from Drive today: every DeleteOptions construction site sets allow_deleting_non_empty_trees: false, the batch path returns NotSupported, and the default is false — so it is a hazard for direct GroveDB API consumers and future Drive features only. Fix is #732 (legacy path byte-exact, corrected behavior gated to GROVE_V3); one ask there before/right after merge: add a Provable*-parent regression test that actually fails on the legacy path, since the PR's current tests pass pre-fix.