[F-29] fix(network): reject oversized peer list responses in get_ipl()

[adequatelimited]

Closes #107

Summary

A peer responding to OP_GET_IPL could include up to 65535 bytes of IP data in the response (the word16 len field maximum). While the consumer loop in scan_quorum() caps netplistidx at 1024, the excess data causes unnecessary iteration — a remote DoS vector for wasting CPU during peer discovery.

Change

Added a bounds check in get_ipl() rejecting responses where len > RPLISTLEN * sizeof(word32) (256 bytes = 64 IPs) — the maximum a legitimate node would ever send via send_ipl().

The original audit also flagged missing opcode validation, but analysis showed this adds minimal value: the chain-state fields (weight, cblockhash, cblock) are filled by send_tx() on the responding side regardless of opcode, so a malicious peer could fabricate them in a legitimate OP_SEND_IPL response just as easily.

Added a TODO noting that received peer IPs should be treated as unverified candidates until confirmed as real nodes, rather than added directly to scan/recent peer lists.

Testing

• Clean build with -Wall -Werror -Wextra -Wpedantic

[adequatelimited]

Audit wanted a response code check for OP_GET_IPL, but practically speaking we know what we're asking for, but on inspection the size of the response was not sanely bounded to the size of the expected RPLISTLEN, so we'll trap on that and return an error code if the replying node sends more peers than that. Merging.