Direct path ambiguity fallback

[robekl]

Summary

This change mitigates one-byte direct-hop collisions by preferring flood routing when a contact’s direct path is ambiguous.

It updates BaseChatMesh so direct-path selection is ambiguity-aware and consistently applied across send/ACK/response/keep-alive paths.

What Changed

• Added direct-path ambiguity detection in BaseChatMesh.
• Added shouldUseDirectPath(...) and switched direct-send decisions to use it instead of only checking OUT_PATH_UNKNOWN.
• Applied this logic in:
  • message send
  • command send
  • request/login/anon request send
  • ACK send path
  • response handling / return-path retry handling
  • keep-alive send path
• Added per-contact cached ambiguity state (direct_path_ambiguous[MAX_CONTACTS]) and cache update helpers.
• Added bounds-safe handling for invalid out_path_len values when evaluating direct-path eligibility.

Why This Is Needed

With one-byte hop prefixes, multiple contacts can share the same prefix. Treating any known out-path as safe for direct routing can select an ambiguous route and reduce delivery reliability. This change makes direct routing conditional on path uniqueness to avoid those cases.

Impact If Included

• Direct routing is used only when the stored path is unambiguous.
• Ambiguous direct candidates fall back to flood routing.
• Improves delivery robustness in collision scenarios.
• Keeps direct-path checks cheap in hot paths via cached ambiguity state.

Impact If Not Included

• Ambiguous direct routes may still be used.
• Higher chance of misrouting/failed direct delivery in prefix-collision cases.
• More retransmits/timeouts in affected topologies.

Benefits

• Better correctness/reliability for direct vs flood routing choice.
• Consistent behavior across all main direct-send call sites.
• Static memory footprint change only (no dynamic allocation).

Drawbacks

• Adds one boolean cache array sized by MAX_CONTACTS.
• Ambiguous cases use flood routing, which can increase airtime versus successful direct routing.