Fix NEW_CONTACT handling to check the live radio contact list before treating nodes as new

[Littleaton]

This PR fixes how the bot handles NEW_CONTACT events. I have not fully tested it, Just thought id PR some ideas on this topic as the bot logging for adverts is annoying if its new or not, its always saying its new.

Right now the bot can log a repeater as newly discovered and “database only” even when the firmware has already added that node to the radio’s contact list. The issue is that the handler was making its decision too early, without checking the live contact state on the radio first.

This change makes the bot check the radio contact list before deciding whether a node is actually new.

Changes

• Refresh the radio contact list before classifying a NEW_CONTACT
• Check both the live radio contacts and the bot tracking database
• Treat the radio contact list as the source of truth for whether the node is already on-device
• If the node is already on the radio:
  • do not log it as new
  • update tracking data in the bot database and continue
• If the node is missing from the radio:
  • treat it as new/missing
  • store it in the bot database
  • attempt to add it to the radio contact list
• Reuse the full NEW_CONTACT payload when adding contacts so path data is preserved
• Skip the new_contact_discovered audit entry for nodes that are already known

Why

In auto_manage_contacts=device mode, the firmware should usually be handling contact creation already. The bot should reflect the actual state of the radio instead of assuming every NEW_CONTACT event means a brand new node.

This makes the logs more accurate and avoids the repeated “new repeater discovered” / “tracking in database only” messages for nodes that are already present.

Expected behavior after this change

When a node advert is heard and a NEW_CONTACT event follows:

• If the node is already in the radio contact list, the bot treats it as known and just updates its own tracking data
• If the node is not in the radio contact list, the bot treats it as new and attempts to sync it into both places

Files

• modules/message_handler.py
• modules/repeater_manager.py
• tests/test_message_handler.py

Validation

• Updated tests for known vs new contact handling
• Verified edited files compile cleanly with python -m py_compile

Note

There is still a possible timing edge case if the firmware has emitted NEW_CONTACT but has not populated the contact table yet by the time the bot checks it. In that case the bot may still treat the node as missing and try to repair it. That fallback is intentional.