[Feature Request] Split contact storage: companion holds crypto-necessary contacts, app manages the rest

[1psmith]

Problem

The companion radio's contact list is a single flat store used for two fundamentally different purposes:

1. Cryptographic contacts — nodes the user exchanges direct messages with, room servers they log into, repeaters they admin. The companion needs these public keys to decrypt, verify, and authenticate.
2. Display-only contacts — repeaters and other nodes heard via flood adverts. The companion stores these solely so the app can map path hashes to human-readable names in the UI. No cryptographic operations depend on them.

On a busy mesh, category 2 fills the contact list quickly, crowding out capacity for category 1. This leads to the bug reported in #1311 (cannot receive DMs when list is full) and the scaling concerns in #1121 and #1227.

The workarounds proposed so far — raising the limit (#1121), auto-evicting old contacts (#1227), contact cleanup preferences (#622) — all treat the symptom. The underlying issue is that the companion's limited flash storage is the single source of truth for contacts that don't need to be there.

Proposal

Separate contact storage into two tiers:

• Companion tier (firmware): Stores only contacts the radio needs cryptographically — nodes the user has messaged, favorited, or manually added, plus room servers and admin'd repeaters. This is bounded by flash and is the constraint that matters.
• App tier (phone/client): Stores all heard adverts — repeater names, public keys, path hash mappings. The app has effectively unlimited storage and can maintain a much larger contact database. When displaying message paths, the app does the hash-to-name lookup locally instead of relying on the companion.

The companion would continue to forward advert data to the app (it already does via PUSH_CODE_ADVERT), but would not need to persist every advert in its own contact table. The app would own the "I've heard of this node" database.

Benefits

• Companion contact slots are reserved for contacts that actually require cryptographic state
• Resolves [Bug] Cannot receive direct messages if contact list is full #1311 — the companion always has room for new DM senders
• Meshes can scale without firmware flash constraints dictating how many nodes a user can be aware of
• No firmware flash layout changes needed for nRF vs ESP32 — the storage pressure moves to the phone

Related issues

• [Bug] Cannot receive direct messages if contact list is full #1311 — Cannot receive direct messages if contact list is full
• Increase contact limit of 300 #1121 — Increase contact limit of 300
• Feature request: keep automatically adding contacts by removing oldest ones unless they are favorite #1227 — Auto-replace oldest non-favorite contacts when full
• [Feature request] Contact list clean-up preferences #622 — Contact list clean-up preferences