#22209: docs(bluebubbles): add dedicated Apple ID guidance and self-chat loop warning

## Summary - Problem: BlueBubbles docs did not explicitly warn against using the same Apple ID for both bot identity and the human operator, while legacy iMessage docs did. - Why it matters: Same-Apple-ID/self-chat setups can create recursive echo loops where prior assistant output is re-ingested as new inbound input. - What changed: Added explicit identity-isolation guidance (dedicated Apple ID + dedicated macOS user) and troubleshooting notes to BlueBubbles docs; aligned macOS VM setup docs to recommend a dedicated bot Apple ID. - What did NOT change (scope boundary): No runtime/channel logic changes, no config schema changes, no webhook/auth behavior changes, no tests/code modifications. - Discovery context: This issue was identified while setting up the BlueBubbles channel on a personal Mac Studio device using a personal Apple ID. ## Change Type (select all) - [ ] Bug fix - [ ] Feature - [ ] Refactor - [x] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [x] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes # (none) - Related #8415 ## User-visible / Behavior Changes - BlueBubbles channel docs now explicitly recommend identity isolation (dedicated Apple ID + dedicated macOS user). - BlueBubbles troubleshooting now documents same-Apple-ID echo-loop signals and clarifies these are separate from webhook password encoding and Private API typing/read 500 noise. - macOS VM iMessage bonus setup now recommends signing in with a dedicated bot Apple ID, not a personal Apple ID. ## Security Impact (required) - New permissions/capabilities? (`No`) - Secrets/tokens handling changed? (`No`) - New/changed network calls? (`No`) - Command/tool execution surface changed? (`No`) - Data access scope changed? (`No`) - If any `Yes`, explain risk + mitigation: - N/A ## Repro + Verification ### Environment - OS: macOS (Sequoia) on personal Mac Studio - Runtime/container: OpenClaw gateway + BlueBubbles server - Model/provider: Any (not model-specific) - Integration/channel (if any): BlueBubbles / iMessage - Relevant config (redacted): `channels.bluebubbles` enabled; same Apple ID used for both bot identity and operator chat context during initial setup ### Steps 1. On a personal Mac Studio, configure BlueBubbles + OpenClaw using the same personal Apple ID used for normal Messages usage. 2. Send messages in a self-context where bot outputs can appear in webhook payloads. 3. Observe webhook/system-style payloads containing prior assistant outputs being ingested as fresh inbound content. 4. Observe repeated embedded runs / recursive reply pattern. ### Expected - Bot should not recursively respond to its own prior outputs. ### Actual - Prior assistant outputs can be re-ingested as inbound input, creating a self-reinforcing echo loop. ## Evidence Attach at least one: - [ ] Failing test/log before + passing after - [x] Trace/log snippets - [ ] Screenshot/recording - [ ] Perf numbers (if relevant) Trace evidence summarized in docs update context: - Repeated BlueBubbles embedded runs. - Inbound content including prior assistant text. - System-style payload patterns such as `System: ... Assistant sent "..."`. ## Human Verification (required) What you personally verified (not just CI), and how: - Verified scenarios: - Reproduced/observed the issue context during BlueBubbles setup on a personal Mac Studio using a personal Apple ID. - Reviewed docs for consistency between `docs/channels/bluebubbles.md`, `docs/install/macos-vm.md`, and legacy `docs/channels/imessage.md`. - Confirmed wording clearly separates this loop pattern from webhook password encoding issues and Private API typing/read 500 noise. - Edge cases checked: - Guidance remains scoped to BlueBubbles/iMessage identity setup. - Scope stays docs-only and does not imply runtime behavior changes. - What you did **not** verify: - No runtime behavior changes were tested because this PR only updates documentation. ## Compatibility / Migration - Backward compatible? (`Yes`) - Config/env changes? (`No`) - Migration needed? (`No`) - If yes, exact upgrade steps: - N/A ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: - Revert this commit/PR. - Files/config to restore: - `docs/channels/bluebubbles.md` - `docs/install/macos-vm.md` - Known bad symptoms reviewers should watch for: - Confusing or over-broad guidance around Apple ID usage. - Any implication that runtime behavior changed in this PR (it did not). ## Risks and Mitigations - Risk: Documentation could be interpreted as a runtime fix rather than setup guidance. - Mitigation: Explicitly state that this PR is docs-only and does not change channel behavior. - Risk: Guidance may be too strong for users intentionally testing self-chat. - Mitigation: Keep recommendation language clear ("strongly recommended") and place details in troubleshooting context. ## AI Assistance - This PR is AI-assisted. - OpenCode session: https://opncd.ai/share/T5Nl1rd7 - Degree of testing: Lightly tested (documentation-only change with human review of updated docs). - Confirmation: I reviewed the generated content and understand the scope and intent of this PR.