The nodeHeight *fullNode case returned maxHeight+1 once the running max
height reached maxHeight via one child: the `if maxH+1 > maxHeight` guard
fired on the next hashNode child, reporting a genuine height-3 branch as
height 4. With the `height == 3` archival predicate this made dense,
branch-heavy tries (notably the account trie, whose height-3 nodes are
all multi-child branches) archive nothing, while only sparse,
extension-heavy storage tries archived anything.
On a jochemnet shadowfork (path scheme, ~379 GB live KV) a 15.5h `archive
generate` archived only 122,340 subtrees / 16.6 MB, and the account trie
archived nothing (count=0), with zero read/collection failures in the
log -- confirming a height computation bug rather than a read-path issue.
Replace the running-max guard with a depth-budget guard mirroring the
already-correct *shortNode case; keep the post-update `maxH > maxHeight`
exceeded check so recursion and raw-DB reads stay bounded.
Add trie/archiver_test.go: a height-3 root branch probes as height 3
(it returned 4 before this change).
Co-authored-by: CPerezz <claude.ai.monorail916@passmail.net>
