fix(gateway): harden BlueBubbles delivery and acknowledgments

[benjaminsehl]

Summary

BlueBubbles can deliver one iMessage as both new-message and updated-message, including overlapping deliveries and later attachment enrichment. This replaces the original persistent-hash approach with bounded in-memory reservation semantics and adds a contextual, turn-local quick acknowledgment for substantive iMessages.

Duplicate-delivery protection

• Canonicalizes equivalent local webhook callbacks and keeps exactly one registration subscribed to both message events.
• Reserves a validated stable message GUID before attachment I/O.
• Makes overlapping duplicate deliveries join one owner outcome, with bounded waiters, attempts, request-wide deadline, cache size, TTL, and attachment count.
• Allows takeover after owner failure and returns retryable HTTP 503 under bounded capacity/deadline pressure instead of dispatching duplicate work.
• Preserves attachment order and dispatches genuinely late media once as attachment-only enrichment.
• Rolls reservations back on download, setup, scheduling, dispatch, cancellation, and enrichment failures so BlueBubbles retries remain possible.
• Retains metadata only; raw webhook payloads are not stored.

Contextual quick acknowledgment

• Optional and BlueBubbles-only; skips slash commands and trivial replies.
• Uses one hard generation/send deadline with reserved fallback budget.
• Accepts only strict pending-work language and never allows acknowledgment failure to abort the main turn.
• Passes visible acknowledgment context into only the exact current agent invocation without mutating conversation history or introducing a synthetic user role.
• Treats empty-message ReadTimeout as an ambiguous send so an already-delivered message does not trigger a duplicate fallback bubble.

Verification

• 192 focused gateway tests pass.
• Ruff, compileall, and git diff --check pass.
• The complete production diff received independent security/logic review after each blocking finding was fixed.
• Clean patch application against current main passes the same 192-test gate.
• Live BlueBubbles verification confirmed one inbound agent run, one acknowledgment, one final response, and exactly one canonical webhook registration.

Test command

python -m pytest \
  tests/gateway/test_bluebubbles.py \
  tests/gateway/test_prompt_tail_freeze.py \
  tests/gateway/test_run_progress_topics.py \
  tests/gateway/test_aiohttp_body_caps.py \
  -o addopts=

[teknium1]

Thanks for the focused BlueBubbles hardening. Current main still subscribes to both events at gateway/platforms/bluebubbles.py:374-377 and dispatches each accepted webhook at :1040, so inbound deduplication remains needed.

Problems

• gateway/platforms/bluebubbles.py:885-895 includes chatGuid in the key but does not use chatIdentifier. The linked #30708 report documents same-GUID deliveries with any;-;+address on one event and only a bare chat identifier on another. Those forms become different keys, so both deliveries can reach the new guard at :1050 and dispatch.

Suggested changes

• Use a GUID-first key, or canonicalize the fallback chat forms, and add an async two-webhook regression covering those differing payload shapes.
• Preserve main's existing log-safe registration URL property at current gateway/platforms/bluebubbles.py:334-340 while salvaging the branch.

Automated hermes-sweeper review.

[teknium1]

This key changes when duplicate BlueBubbles events expose the same message GUID under different chat forms. The linked #30708 report shows any;-;+address on one event and only a bare chat identifier on the other; because chatIdentifier is not considered here, they become different keys and both dispatch. Please key GUID-first or canonicalize the fallback identifiers, with an end-to-end two-webhook regression.