openclaw - 💡(How to fix) Fix iMessage: decide whether to support automatic ack tapbacks

Summary

#81311 originally grouped three iMessage private-API behaviors together: typing indicators, read receipts, and automatic tapback acknowledgements.

Current main already covers the runtime wiring parts:

• Typing indicators and read receipts were added by #78317.
• Inbound tapbacks are routed as reaction events by #80713.
• Approval prompts can be resolved with iMessage thumb tapbacks by #85952.

The remaining question is narrower: should the iMessage plugin send an automatic tapback acknowledgement when it accepts an inbound message?

Current behavior

• iMessage marks accepted inbound chats read when the private API bridge supports read, unless channels.imessage.sendReadReceipts: false.
• iMessage sends typing start/stop while the agent is generating when the private API bridge supports typing.
• iMessage supports manual/tool tapbacks and approval tapbacks.
• iMessage does not currently send a generic automatic ack tapback on every accepted inbound message.

That last point is expected today, not a bridge wiring bug.

Product/API decision

Decide whether automatic iMessage ack tapbacks should exist at all. WhatsApp has an explicit channels.whatsapp.ackReaction contract, but iMessage tapbacks are more conspicuous in the conversation and may create notification/noise tradeoffs that are different from read receipts.

If we add this, likely shape:

• Add an opt-in iMessage config such as channels.imessage.ackReaction rather than enabling by default.
• Gate it on private API tapback support and channels.imessage.actions.reactions !== false.
• Define direct/group semantics explicitly instead of inheriting ambiguous legacy message-level behavior.
• Document that read receipts remain the default lightweight acknowledgement path.
• Add focused tests for config/schema, accepted inbound dispatch, group/DM gating, unsupported bridge behavior, and no-op behavior when disabled.

Acceptance criteria

• Maintainer decision recorded: support opt-in automatic ack tapbacks, or document read receipts as the supported iMessage acknowledgement.
• If supported, implementation and docs are aligned with the chosen config contract.
• If declined, iMessage docs explicitly say generic automatic ack tapbacks are not sent and point users to read receipts / approval reactions / manual reactions instead.

Refs #81311.