doctor: detect data-plane drift when readiness is green but chats/accounts are missing #46

Summary

beeper doctor currently reports the target as healthy when the process/readiness layer is healthy, even if the user-visible data plane is clearly inconsistent.

We now have multiple examples of this class:

• chats list and contacts list return empty on self-hosted server (data exists in DB) #14: doctor/readiness is healthy, message search returns data, but chats list and contacts list are empty.
• Server 4.3.152: local-facebook / local-instagram missing from /v1/accounts and /v1/chats, not restarted on boot #38: bridge logins completed and data initially flowed, but Facebook/Instagram disappear from /v1/accounts / /v1/chats after restart.
• desktop-api-js#36: native iMessage chats exist while /v1/accounts omits the iMessage account.
• feat: make native iMessage discoverable and directly sendable #42 adds an iMessage-specific diagnostic, which exposed the broader pattern: one API surface cannot safely be treated as the sole proof of health.

Proposed diagnostic

Add an opt-in deeper data-integrity probe, for example:

beeper doctor --data

or make the existing doctor report a non-fatal dataIntegrity section.

The probe should cross-check independent surfaces rather than trusting one endpoint:

• readiness / target live status
• /v1/accounts
• recent /v1/chats results
• bridges and their account/login state when available
• a lightweight message-search capability check when there is enough information to do so safely

Useful degradations to identify:

1. accounts missing, chats present → account-discovery drift
2. bridge/login present, account missing → bridge/index drift
3. accounts present, chats unexpectedly empty → chat-index/bootstrap drift
4. message search has data while chats list is empty → strong evidence that the target is operational but its chat index/API surface is degraded

Behavior

• Do not send messages or mutate state.
• Keep ordinary process readiness separate from data-plane readiness.
• Report evidence and suggested next action instead of collapsing everything into a single healthy/unhealthy boolean.
• JSON output should be stable enough for agents/monitoring to act on.

Why

A green process-level doctor result is actively misleading when the messaging/search surfaces an agent relies on are empty or incomplete. The CLI is in a good position to reconcile these signals even when the underlying Desktop/Server bug is closed-source.

This is a generalization of the iMessage integrity work in #42, not a replacement for the underlying server bugs in #14/#38.