feat: make native iMessage discoverable and directly sendable

[b-pm]

Summary

Make Apple Messages/iMessage usable from the CLI even when the Desktop accounts API omits the native account.

This adds:

• native iMessage account discovery by reconciling /v1/accounts with iMessage chats
• inferred iMessage rows in accounts list
• account-selector resolution for iMessage / inferred imessage_* account IDs
• accounts show fallback when the inferred native account is not retrievable from /v1/accounts/{id}
• direct-recipient sending with --account across text, file, sticker, and voice sends
• beeper doctor --network imessage diagnostics for:
  • native account visibility
  • contact-name resolution gaps
  • the known iMessage page-2 history/cursor failure

Why

Today iMessage can be connected and fully usable in Beeper while GET /v1/accounts omits it. That makes accounts list, account-based filters, and agent workflows report a false negative.

It also makes outbound automation unnecessarily brittle because a sender has to find an existing chat first. With this PR, an explicit account turns --to into a recipient identity and asks Beeper to reuse or start the direct chat:

beeper send text --account iMessage --to +15551234567 --message "Checking in"
beeper send file --account iMessage --to +15551234567 --file ./proposal.pdf

The native bridge also currently has a cursor conversion issue where older-history pagination can return an empty second page. The network-specific doctor probe makes that failure explicit instead of letting an operator assume history ended.

Related:

• get_accounts does not return iMessage even when iMessage is active and functional desktop-api-js#36
• iMessage chat participants returned as raw phone numbers / opaque hashes instead of contact names desktop-api-js#37
• iMessage pagination fails due to Unix ms cursor mismatch desktop-api-openapi#3

Safety / behavior

• Existing account API rows remain authoritative.
• Inference runs only when the accounts API has no iMessage account.
• Inferred rows are marked native: true and inferredFrom: "chats".
• Existing send --to chat-selector behavior is unchanged unless --account is supplied.
• --account uses Beeper's existing /v1/chats/start semantics, which reuse an existing direct chat when available.
• No diagnostic command sends messages or logs message contents.
• Broken iMessage history pagination is reported as a degradation, not treated as proof that messaging is unavailable.
• Generic beeper doctor behavior is unchanged unless --network imessage is supplied.

Tests

Adds coverage for:

• chat-derived native account discovery
• resolving iMessage to the inferred account ID
• direct-recipient send target resolution through an inferred iMessage account
• detecting the empty second-page pagination signature
• healthy pagination
• no-account/no-chat behavior

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[b-pm]

@batuhan this is aimed at the native iMessage gap behind desktop-api-js#36: account discovery can be false-negative even while iMessage chats work. This PR keeps existing account rows authoritative, infers only when needed, adds a focused doctor --network imessage, and lets explicit --account iMessage --to <phone/email> sends reuse/start a direct chat. CI is currently blocked at the fork approval gate (action_required, no jobs created). A maintainer review of the current head would be very helpful.