Investigate alternative subtree layout for `LargeSmt`

Current subtrees use depth `8` (`~16KB` per subtree). Smaller subtrees (e.g. depth `6`) would reduce typical read/write size to `~4KB` (closer to page size). The last subtree could also be larger (e.g. depth `16`) to handle sparsity.

Candidate layouts to explore (including the in-memory portion):
- `[24, 6, 6, 6, 6, 16]`
- `[26, 6, 8, 8, 16]`

Evaluate tradeoffs in I/O size vs. implementation complexity and decide if a new layout is worthwhile.

Derived from PR 0xMiden/crypto#438 [comment](https://github.com/0xMiden/crypto/pull/438#discussion_r2328371607).