Improve retransmission logic when only one node is rebroadcasting repeatedly

[stm32repo]

Current behavior:
Right now, when a sender transmits a packet and hears at least one rebroadcast of that packet (i.e. hears its own packet ID being repeated by someone), it considers the packet successfully delivered to the mesh and stops further retransmissions (implicit ACK via rebroadcast).Problem / Observed issue:
In some topologies — especially when there is only one active neighbor that can hear the original sender — we can end up in a situation where a single node keeps rebroadcasting the same packet multiple times (up to hop limit or until it hears someone else rebroadcast it), but that node has no further path to propagate the message.
The original sender sees those repeated rebroadcasts and treats each of them as another "successful" implicit ACK, so it never triggers its own retransmission logic.Proposed improvement:
Add a heuristic / additional check in the retransmission logic:
If the sender hears ≥ 3 rebroadcasts coming from the exact same node (same sender ID) and no rebroadcasts from any other nodes, then assume this is a "dead-end" relay and treat it as not sufficient propagation.
In this case the original sender should trigger an additional retransmission (even though it has already seen rebroadcasts).Why this matters: Improves delivery in asymmetric / sparse meshes where one weak link can trap packets.
Very low risk of creating broadcast storms, because the condition is quite strict (many repeats + only from one node).
Does not break the existing implicit-ACK logic in normal multi-path or denser networks.

Possible implementation sketch (very high-level): Keep a small per-packet-ID counter / map: node_id → count_of_rebroadcasts_heard_from_this_node
When deciding whether the packet is "done", check not only "was at least one rebroadcast heard?", but also:
if (total_rebroadcasts_heard >= 3 && max_rebroadcasts_from_single_node >= 3 && unique_nodes_that_rebroadcasted == 1) → treat as failure → retransmit

What do you think? Is something like this worth experimenting with, or is there already a better way to detect such trapped packets?Thanks!