CLAUDE.md: record the beacon's inherent mDNS noise limitation

Network churn (SSID jump/roam) makes adbd re-publish its advertisement
repeatedly; each resolve re-arms the connection and posts a notification,
so the resolve-once guard can't fully prevent spam on the OnePlus. Noted
the alternatives (manual port, or Shizuku `ss` with no mDNS involved).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md

@@ -94,6 +94,12 @@ First build downloads AGP/Compose/Shizuku from Google Maven + Maven Central.
   periodic heartbeat only re-POSTs the cached port. Rotation is still caught: onServiceLost
   clears the guard, so the new advertisement is resolved once and reported within seconds
   (verified: 37089 -> 33667 reported 6 s after rotation).
+  **Known limitation — do not run the beacon on the OnePlus.** On network churn (SSID jump, roam)
+  adbd repeatedly drops and re-publishes its advertisement, so lost/found cycles keep clearing the
+  resolve-guard; each resolve makes adbd re-arm and post a "wireless debugging connected"
+  notification. Guarding reduces but cannot eliminate this — resolving adbd's own mDNS record is
+  inherently noisy on that device. Use manual `ip:port` there (ask the user), or read the port via
+  Shizuku (`ss -tlnp | grep adbd`, no mDNS) if the shell tier is available.
 - **Shizuku start kills the adb bridge and the beacon can't auto-recover it.** Shizuku's non-root
   start pairs over wireless debugging and runs its starter through adb, hijacking the channel:
   adb goes device→offline→refused, and adbd keeps advertising the now-dead port over mDNS (stale),