Fix discv5 ENR refresh installation

[MysticRyuujin]

Summary

• install newer ENRs returned by distance-zero FINDNODE requests
• require the returned ENR to belong to the responding node
• select the highest-sequence matching record
• invoke the existing OnNodeUpdate callback after installation so the node is reclassified
• add regression coverage for successful refreshes, wrong-node records, and stale records

Root cause

When a peer advertised a higher ENR sequence in PING or PONG, requestENRUpdate sent a distance-zero FINDNODE request but only logged the returned NODES record. The cached session ENR was never replaced, despite a comment claiming the NODES handler updated it automatically.

For peers whose startup ENR lacked usable fork data, bootnodoor therefore kept the node unclassified and returned empty NODES responses to it indefinitely. Erigon reproduced this behavior: it completed a discv5 session, but remained outside the EL table with zero peers.

Safety

Returned records are structurally validated and must derive the same node ID as the responder. Only a strictly newer record is installed, preventing a peer from replacing its session record with another node's ENR. If several records are returned, the newest matching record wins.

Validation

• go test ./...
• go vet ./...
• gofmt -s -l .
• go test -race ./discv5/protocol ./bootnode

End-to-end validation used a fresh multi-client Kurtosis devnet. After the fix:

• bootnodoor admitted Erigon with its high-sequence, current-fork ENR
• Erigon reached four peers instead of remaining isolated
• every node discovered by the crawler was in its verified capacity class

Nethermind and nimbus-eth1 bootstrapping are separate interop issues and are out of scope for this change.

[cskiraly]

I've bumped into the same issue. Fix looks good to me.