### Summary
BlueBubbles is an optional OpenClaw channel plugin. A configuration-sensitive access-control mismatch allowed DM senders to be treated as authorized when `dmPolicy` was `pairing` or `allowlist` and `allowFrom` was empty/unset.

### Severity Rationale (Medium)
Severity is set to **medium** because:
- this affects an optional plugin, not core messaging surfaces;
- many deployments use owner-controlled/private BlueBubbles identities with limited external reachability;
- practical exploitability depends on an untrusted sender being able to reach that specific BlueBubbles account identifier.

In typical personal/self-hosted BlueBubbles setups, the mapped Apple identity is single-owner and not broadly reachable, so this is usually low practical risk.

Risk is higher in deployments where the identifier is publicly reachable and/or agent tool permissions are broad.

### Technical Details
1. BlueBubbles DM policy defaults to `pairing` (`dmPolicy ?? "pairing"`).
2. Effective allowlist can be empty (`effectiveAllowFrom`).
3. DM/reaction authorization called `isAllowedBlueBubblesSender(...)`.
4. That delegated to shared `isAllowedParsedChatSender(...)`, which previously returned `true` for empty allowlists.
5. Result: unknown senders could bypass intended pairing/allowlist gating when `allowFrom` was empty.

### Affected Packages / Versions
- Package: `openclaw` (npm)
- Vulnerable versions: `<= 2026.2.21-2`
- Planned fixed version: `2026.2.22`

### Fix
The shared parsed-chat allowlist helper now fails closed on empty allowlists, restoring expected BlueBubbles DM gating behavior. BlueBubbles inbound gating was also refactored to use one shared DM/group decision helper for both message and reaction paths to reduce future drift.

### Fix Commit(s)
- `9632b9bcf032c5f2280c3103961fde912ab1f920`
- `2ba6de7eaad812e5e8603018e14e54e96bdd57dd`
- `51c0893673de8e5cea64e64351dbfa4680ba0dec`
- `4540790cb62412676f7b61cfc6e47443f84a251e`

OpenClaw thanks @tdjackey for reporting.

CWE-863 Incorrect Authorization