fix: align open DM allowlist policy (#74112)

* fix: harden telegram open dm allowlist merging

* fix: align open dm allowlist policy

docs/channels/feishu.md

@@ -45,7 +45,7 @@ Configure `dmPolicy` to control who can DM the bot:
 
 - `"pairing"` — unknown users receive a pairing code; approve via CLI
 - `"allowlist"` — only users listed in `allowFrom` can chat (default: bot owner only)
-- `"open"` — allow all users
+- `"open"` — allow public DMs only when `allowFrom` includes `"*"`; with restrictive entries, only matching users can chat
 - `"disabled"` — disable all DMs
 
 **Approve a pairing request:**

docs/channels/pairing.md

@@ -21,6 +21,11 @@ When a channel is configured with DM policy `pairing`, unknown senders get a sho
 
 Default DM policies are documented in: [Security](/gateway/security)
 
+`dmPolicy: "open"` is public only when the effective DM allowlist includes `"*"`.
+Setup and validation require that wildcard for public-open configs. If existing
+state contains `open` with concrete `allowFrom` entries, runtime still admits
+only those senders, and pairing-store approvals do not widen `open` access.
+
 Pairing codes:
 
 - 8 characters, uppercase, no ambiguous chars (`0O1I`).

docs/channels/synology-chat.md

@@ -93,8 +93,8 @@ Config values override env vars.
 
 - `dmPolicy: "allowlist"` is the recommended default.
 - `allowedUserIds` accepts a list (or comma-separated string) of Synology user IDs.
-- In `allowlist` mode, an empty `allowedUserIds` list is treated as misconfiguration and the webhook route will not start (use `dmPolicy: "open"` for allow-all).
-- `dmPolicy: "open"` allows any sender.
+- In `allowlist` mode, an empty `allowedUserIds` list is treated as misconfiguration and the webhook route will not start (use `dmPolicy: "open"` with `allowedUserIds: ["*"]` for allow-all).
+- `dmPolicy: "open"` allows public DMs only when `allowedUserIds` includes `"*"`; with restrictive entries, only matching users can chat.
 - `dmPolicy: "disabled"` blocks DMs.
 - Reply recipient binding stays on stable numeric `user_id` by default. `channels.synology-chat.dangerouslyAllowNameMatching: true` is break-glass compatibility mode that re-enables mutable username/nickname lookup for reply delivery.
 - Pairing approvals work with:
@@ -172,7 +172,7 @@ but duplicate exact paths are still rejected fail-closed. Prefer explicit per-ac
 - `Rate limit exceeded`:
   - too many invalid token attempts from the same source can temporarily lock that source out
   - authenticated senders also have a separate per-user message rate limit
-- `Allowlist is empty. Configure allowedUserIds or use dmPolicy=open.`:
+- `Allowlist is empty. Configure allowedUserIds or use dmPolicy=open with allowedUserIds=["*"].`:
   - `dmPolicy="allowlist"` is enabled but no users are configured
 - `User not authorized`:
   - the sender's numeric `user_id` is not in `allowedUserIds`

docs/channels/telegram.md

@@ -114,6 +114,7 @@ Token resolution order is account-aware. In practice, config values win over env
     `dmPolicy: "open"` with `allowFrom: ["*"]` lets any Telegram account that finds or guesses the bot username command the bot. Use it only for intentionally public bots with tightly restricted tools; one-owner bots should use `allowlist` with numeric user IDs.
 
     `channels.telegram.allowFrom` accepts numeric Telegram user IDs. `telegram:` / `tg:` prefixes are accepted and normalized.
+    In multi-account configs, a restrictive top-level `channels.telegram.allowFrom` is treated as a safety boundary: account-level `allowFrom: ["*"]` entries do not make that account public unless the effective account allowlist still contains an explicit wildcard after merging.
     `dmPolicy: "allowlist"` with empty `allowFrom` blocks all DMs and is rejected by config validation.
     Setup asks for numeric user IDs only.
     If you upgraded and your config contains `@username` allowlist entries, run `openclaw doctor --fix` to resolve them (best-effort; requires a Telegram bot token).