NRG: Invalidate pae cache on WAL truncate and snapshot install

[MauriceVanVeen]

n.pae caches append entries and is normally drained by applyCommit. Three paths bypassed that drain: truncateWAL, installSnapshot, and catchup-from-snapshot. Memory would leak (bounded by paeDropThreshold) and the cache would become less efficient, requiring more disk loads until a stepdown or server restart.

[synadia-claude-reviewer]

Claude finished @MauriceVanVeen's task in 3m 46s —— View job

---

PR Review

• Gather context and read CLAUDE.md
• Read PR diff and changed files
• Analyze changes for correctness, concurrency safety, and performance
• Post inline review comments
• Post review summary

---

Verdict: LGTM — correct fix, well-tested.

The PR correctly addresses three distinct paths where n.pae could survive past the entries it was caching:

truncateWAL: Selective delete (index > truncation point) is the right approach — it preserves still-valid cache entries rather than wiping everything. Lock ordering is safe: the WAL is truncated first, then the cache is invalidated, all under the node lock, so applyCommit cannot observe a split state.

installSnapshot (direct call): The condition snap.lastIndex > n.commit is correct — entries ≤ n.commit have already been evicted from n.pae by applyCommit's defer delete(...). Only uncommitted entries at indices (n.commit, snap.lastIndex] are stale after WAL compaction.

Catchup snapshot reordering: This is the subtle and crucial fix. Before, n.commit = ae.pindex was set before calling installSnapshot, making the clearing condition inside trivially false (snap.lastIndex == n.commit). The reordering ensures the old n.commit is compared against the snapshot index, correctly triggering the cache flush. Bonus: if installSnapshot errors, the node fields are now left unchanged rather than in a partially-mutated state.

Tests: All four test functions clearly exercise the intended scenario, use the existing single-node test harness, and check both the positive (correct state after) and negative (cache is gone) conditions.

Minor observations (neither blocking nor new to this PR):

• When n.pae = make(map[uint64]*appendEntry) is called, the abandoned *appendEntry pool objects are not returned to aePool. This is consistent with the pre-existing pattern in switchToLeader (line 5131) — GC will collect them, so no true leak, but pool reuse efficiency is reduced.
• The full-wipe in installSnapshot also drops any entries at indices > snap.lastIndex that would still be valid in the WAL. Acceptable for a recovery path; and in practice the caller immediately sets n.pindex = ae.pindex, so there are no such future-indexed entries anyway.

[sciascid]

LGTM