fix: prevent MTU clamp to zero when previous-hop has no HW_MTU

[jrl290]

Problem

When forwarding a LINKREQUEST through a transport node, the MTU clamping logic in Transport::inbound() uses std::min(nh_mtu, ph_mtu) to pick the lower of the next-hop and previous-hop interface MTUs.

However, when the previous-hop interface has no HW_MTU configured (ph_mtu == 0), std::min(nh_mtu, 0) clamps the path MTU to zero instead of using nh_mtu.

This happens when:

1. A LINKREQUEST enters via an interface that doesn't report an HW_MTU
2. nh_mtu < path_mtu is true (so the clamping branch executes)
3. ph_mtu is 0 from initialization → std::min(nh_mtu, 0) = 0

The result is a zero-byte MTU in the signalling bytes, which causes the link to either fail or produce unusable segment sizes.

Fix

Change:

path_mtu = std::min(nh_mtu, ph_mtu);

To:

path_mtu = std::min(nh_mtu, (ph_mtu > 0) ? ph_mtu : nh_mtu);

When ph_mtu is 0 (unknown/unconfigured), fall back to nh_mtu rather than clamping to zero.

Testing

Discovered and verified on ESP32 transport nodes (Heltec V3/V4) forwarding LXMF resource transfers between TCP clients. Without this fix, resource transfers through the transport node stall permanently when the inbound interface lacks an HW_MTU value.

[attermann]

Simple yet effective. TY.