fix: defer packet hashlist insertion for link-table and LRPROOF packets

[jrl290]

Problem

The C++ code unconditionally adds every accepted packet's hash to _packet_hashlist immediately after packet_filter(), before link transport or proof handling runs:

_packet_hashlist.insert(packet.packet_hash());  // Always, immediately

The Python reference implementation (Transport.py lines 1362-1373) defers insertion for two cases:

1. Packets whose destination_hash is in link_table (link data packets) - hash added later, inside the link transport forwarding block, only after a valid outbound direction is confirmed (Transport.py line 1544)
2. LRPROOF packets (type=PROOF, context=LRPROOF) - hash is never added, allowing duplicate proofs to be processed on multiple interfaces

Impact

On shared-medium interfaces (e.g. LoRa), a packet belonging to a link that transports through this node may arrive on the "wrong" interface first (e.g. overheard on LoRa before arriving via TCP backbone). The premature hash insertion causes the arrival on the correct interface to be filtered as a duplicate by packet_filter(), breaking link transport for non-resource contexts (DATA ctx=0, LINKIDENTIFY, LRRTT, LINKCLOSE).

Resource contexts (RESOURCE, RESOURCE_REQ, RESOURCE_PRF) are unaffected because they bypass the hashlist check in packet_filter.

Fix

1. Before inserting into _packet_hashlist, check if the packet's destination_hash is in _link_table or if it's an LRPROOF packet. If so, defer the insertion.
2. Add _packet_hashlist.insert() inside the link transport forwarding block, after the outbound direction is confirmed and the packet is transmitted.

This matches the Python reference implementation's behavior exactly.

[attermann]

I can see there's quite a bit more work to do in this area to bring it current with the latest reference. I'm merging this for now and will bring the rest up to date soon.