Resource reception not implemented: RESOURCE_ADV handler is commented out in Link.cpp

[Giak88]

Summary

Incoming Resource transfers over an established Link are never
processed. Resource::accept() is not implemented, and the
Type::Packet::RESOURCE_ADV case in Link.cpp is inside a /*z ... */
comment block. This makes it impossible to receive LXMF messages on a
microReticulum node, since LXMF delivers messages as Resources over Links.

Environment

• microReticulum 0.2.10 (via varna9000/microReticulum_Firmware)
• nRF52840 (Heltec Mesh Node T114, SX1262)
• Peer: Sideband on Android

Observed behaviour

Link establishment works and is fast — 179 ms from request to proof:

11:01:11.814 [RX ] 86B via LoRaInterface
11:01:11.879 [VRB] Validating link request b65d7cf808470db511f83b001376829e
11:01:12.058 [TX ] 118B via LoRaInterface

All resource chunks then arrive at the radio layer:

[RX ] 83B
[RX ] 243B
[RX ] 99B
[RX ] 51B

No further TX follows. ~20 s later the peer times out and opens a new
link with a fresh ID, repeating indefinitely. Transport statistics
confirm nothing is completed: lt: 0 rcp: 0 across the whole session.

Cause

In src/Link.cpp, the RESOURCE_ADV case (around line 1144) is entirely
within /*z ... */. Beyond being disabled, the block would not compile
as-is — it still contains Python syntax carried over from the reference
implementation:

• elif _object->_resource_strategy == ACCEPT_ALL:
• RNS.Resource.accept(packet, _object->_callbacks.resource_concluded)
• Python keyword-argument calls: Resource::accept(packet, callback=...)

In src/Resource.cpp, grep -n "accept\|RESOURCE_PRF\|send_proof"
returns nothing — the receive path (accept, part reassembly, hashmap
handling, proof generation) has no implementation.

Note that Resource::validate_proof() exists, but that is the sending
side verifying an incoming proof, not the receiving side generating one.

Impact

Any node built on microReticulum can act as a transport node but cannot
be addressed directly. Transport, path table and announce forwarding all
work correctly — this affects only Resource reception. Board-independent.

Notes

Resource.h:22 records that std::function is unavailable on the NRF52
framework, so callbacks use raw function pointers. Worth keeping in mind
for whichever design the receive path adopts.