[chrisbutler]

The BlueBubbles connector currently maps reactions into the six classic Tapbacks. This loses distinctions such as a blue heart versus a red heart, a skin-tone thumbs-up versus a plain thumbs-up, and arbitrary Unicode reactions. Stored reactions also need their original Unicode value for replacement/removal after a restart.

Add opt-in Unicode Tapbacks behind an optional connector interface, with the existing behavior retained for other connectors and servers without the capability. Require macOS 26+, an enabled private API, and the server's checked custom_emoji_reactions capability. Preserve the complete Unicode value through incoming JSON, sending, history/backfill, database storage, replacement, and redaction. Schema 22 adds a default-empty custom_emoji field for existing classic records. A failed remote removal keeps the local reaction record available for retry.

Publish BlueBubbles reaction capabilities in com.beeper.room_features at the bridge state key and the empty key used by current Android room-state refresh. Unicode mode omits the six-emoji allowlist and still allows one reaction per sender; uploaded/image emoji remain unsupported. Capability cache IDs include the whole feature payload. Explicit SMS rooms retain conservative classic-reaction and transport restrictions.

Enable with imessage.bluebubbles_custom_emoji_reactions: true only on a server/helper with the companion capability changes. Companion drafts: BlueBubblesApp/bluebubbles-server#870 and BlueBubblesApp/bluebubbles-helper#78 . The server contribution is stacked on BlueBubblesApp/bluebubbles-server#839 and credits that existing work.

Validation:

• go test ./... passes on macOS arm64.
• go test -race ./imessage/bluebubbles passes.
• Tests cover exact Unicode sequences, legacy fallback, HTTP add/remove payloads and capability gates, incoming JSON variants, multipart targets, migration of classic rows, Unicode replacement/persistence after reopening the DB, capability state payloads, and retry after a failed remote removal.

Draft review items:

• Agree on the server/helper capability contract and room-feature publication shape.
• Capability detection is currently a connector-startup snapshot; the server revalidates each request, while reconnect-time capability refresh remains a review item.
• Validate live integration of these isolated branches and older-macOS fallback. A predecessor custom stack has user-confirmed Android/Desktop/Messages Unicode delivery, but this review branch has not been deployed over it.
• Beeper Android 4.60.0 still imposes a six-emoji picker for imessagego. This PR preserves the protocol identity; the account-specific generic-protocol workaround and SMS room allowlists are kept out of this contribution. The Android client needs a separate picker/capability fix.

This PR is independent of contact sync #238. It includes no user room IDs, contact records, credentials, compiled binaries, or local installation policy. Implementation and tests were developed with Codex assistance.