fix(companion): also clear stale contact refs on silent auto-eviction

onContactOverwrite() (the contact-table-full LRU eviction path) deleted the
contact's blob and notified the companion app, but never called the new
onContactRemoved() cleanup -- so a Favourites Dial slot, Locator target, or
Live Share target could still go stale, just via the silent auto-evict path
instead of an explicit removal. This is likely the main real-world cause of
the "(gone)" tile the docs described, since auto-eviction happens far more
often than an explicit CMD_REMOVE_CONTACT.

Also sync the two docs that described the old (now wrong) behaviour:
Locator's "survives delete" claim, and Favourites Dial's "(gone) until
reassigned" claim.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

examples/companion_radio/AbstractUITask.h

@@ -73,9 +73,11 @@ public:
   virtual void onSharedLocation(const uint8_t* pub_key, const char* name,
                                 int32_t lat_1e6, int32_t lon_1e6,
                                 uint32_t ts, bool verified) {}
-  // A contact was removed (companion app / CLI command). Lets UI state that
-  // references contacts by pubkey (favourite slots, the Locator/Live Share
-  // target) drop a reference that would otherwise dangle. Default no-op.
+  // A contact is gone — removed explicitly (companion app / CLI command) or
+  // silently auto-evicted to make room when the contact table is full. Lets
+  // UI state that references contacts by pubkey (favourite slots, the
+  // Locator/Live Share target) drop a reference that would otherwise dangle.
+  // Default no-op.
   virtual void onContactRemoved(const uint8_t* pub_key) {}
   virtual void loop() = 0;
 };