discv5: guard Node with a mutex to prevent poll/injectDatagram data race

[ch4r10t33r]

Root cause

Node is designed as a poll-based, single-threaded system, but callers routinely run poll() in a dedicated thread (the drive loop) while delivering packets via injectDatagram() from a separate thread (e.g. a shared UDP receive loop or a simulation transport that forwards packets between nodes).

Without synchronisation the two paths race on pending and challenge_pending (both ArrayListUnmanaged). A concurrent append in injectDatagram can reallocate the backing buffer while expireRequests (called from poll) is mid-iteration. The drive-loop thread can then observe a stale or partially-written items.len, causing swapRemove to be invoked on what appears to be an empty list:

thread NNNNN panic: integer overflow
std/array_list.zig:964:32: if (self.items.len - 1 == i) return self.pop().?;
discv5/node.zig:expireRequests: _ = self.pending.swapRemove(i);

This was the crash observed in zeam when running a multi-node simulation (zeam beam).

Fix

Add a std.Thread.Mutex field mu to Node (zero-initialised at declaration, no API change to init()). Both public entry points that mutate node state acquire the lock for their full duration:

• poll() – holds mu across recvLoop, expireRequests, and refreshBuckets
• injectDatagram() – holds mu across the packet-dispatch switch

All internal helpers (handleOrdinary, handleWhoareyou, handleHandshake, expireRequests, sendPing, sendFindNode, …) are private and therefore automatically protected when called from either entry point.

Test plan

• zig build test --summary all – all 145 tests pass
• zig fmt --check src/discovery/discv5/node.zig – clean

[ch4r10t33r]

Closing — root cause is in zeam's pollLoop (double discv5.poll call), not in zig-ethp2p itself.