Unbounded rterm/rte allocation during stage2 extended-range TERM collection — attacker-controlled kernel-heap exhaustion at mount ('This must fit in memory!' is not enforced)

Summary

hammer_recover_stage2's reverse scan of the extended range calls hammer_recover_redo_rec for every REDO_TERM_* record: one kmalloc(M_WAITOK) rterm per unique (objid, localization, flag, offset) (:1177) plus one kmalloc'd rterm_entry per record occurrence appended to the matching rterm's list (:1202-1205); all freed only at end of stage2 (:731-738). The extended range spans up to the whole undo FIFO (up to 128 bigblocks = 1GB), every record byte is attacker-crafted with matching CRCs and monotonically decreasing seqnos (:659-666), so ~16M crafted TERM records (64B each on disk) allocate ~1.1GB of non-pageable kernel heap during mount - memory-exhaustion DoS / M_WAITOK stall. The design comment admits the constraint ('This must fit in memory!', :611) but nothing enforces a bound. Requires the largest crafted image of the hammer family for the least impact - Low, not guest-verified per contract. Fix: cap total rterm+rte allocations, fail stage2 EIO when exceeded (REDO replay optional by design).