fix(bluebubbles): send-only standalone delivery collides with live webhook

[krullma]

Summary

Cron/standalone delivery builds a one-shot BlueBubblesAdapter to POST a message while the gateway live adapter already holds the webhook listener. Three failure modes, all reproduced on a real BB deployment (macOS, gateway + BB server on same host):

1. EADDRINUSE on every fallback send — connect() unconditionally binds webhook_host:webhook_port; a second bind on 8645 fails with [Errno 48] address already in use, killing the send before it runs. Cron jobs that hit the standalone fallback silently delivered nothing.
2. disconnect() wipes the live webhook registration — the one-shot adapter unregisters its webhook URL, which is byte-identical to the live adapter's. BlueBubbles stops receiving inbound events; outbound REST keeps working so nothing looks broken. Inbound iMessage dies silently.
3. Registration URL rewritten to localhost — _webhook_url normalizes 127.0.0.1 → localhost; the listener binds IPv4 only and macOS resolves localhost to ::1 (IPv6) first, so BlueBubbles POSTs events at a dead port. Inbound dies again, differently.

Fix

• Add connect_send_only (from platform extra or BLUEBUBBLES_CONNECT_SEND_ONLY): connect() pings the server then skips the webhook bind/register; disconnect() skips the unregister.
• tools/send_message_tool._send_bluebubbles sets the flag (it builds a one-shot adapter by design).
• _webhook_url keeps the literal 127.0.0.1 instead of rewriting to localhost.

Test Plan

• 28 tests pass in tests/gateway/test_bluebubbles.py (24 existing + 4 new: send-only flag from extra/env, default off, and send-only disconnect must not call _unregister_webhook; webhook URL tests updated to assert 127.0.0.1 survives normalization).
• Live E2E on macOS: standalone send via _send_bluebubbles succeeds (SendResult.success=True), no second bind on 8645, webhook registration intact after disconnect, and inbound iMessage events reach the gateway again (verified by sending a reply from the phone).

[alt-glitch]

This was generated by AI during triage.

Duplicate of #51763 for the standalone send-only lifecycle: it already avoids the webhook bind/register/unregister collision. This branch also carries loopback normalization work from the existing BlueBubbles repair family; please split or rebase any distinct portion.

[krullma]

Agreed — closing this as duplicate. #51763 covers the send-only bind/unregister lifecycle (same root cause, cleaner API via connect(send_only=True)), and #97672 covers the loopback normalization.

One thing worth adding for the other two PRs, from a real deployment (macOS, gateway + BlueBubbles server on the same host, cron delivery + inbound iMessage):

• E2E evidence for fix(bluebubbles): skip webhook server bind in standalone send path (salvage of #12439 by @Wonham) #51763: with the send-only fix live, standalone cron delivery succeeds (SendResult.success=True), no second bind on 8645, and the webhook registration survives disconnect() (verified against /api/v1/webhook before/after).
• E2E evidence for fix(bluebubbles): preserve IPv4 webhook address #97672: with localhost registered, BlueBubbles POSTs events to ::1 while aiohttp listens on IPv4 only — inbound iMessage replies silently vanish while outbound REST still works. After re-registering the literal 127.0.0.1 URL, inbound events arrive again (verified by phone → gateway round trip).

Both were reproduced and fixed locally; happy to help review either PR.

Also: the send-only flag currently on my branch reads from platform extra/env; #51763's signature-based approach is strictly better.