fix(matrix): restore allowlist fallback for dm/group policies

[Sid-Qin]

Summary

• Problem: Matrix monitor only read dm.policy + dm.allowFrom and ignored legacy dmPolicy/allowFrom fields; group allowlist mode also did not fall back to DM allowlist when groupAllowFrom was unset.
• Why it matters: allowlist deployments could silently block inbound DM/group messages after config migrations or mixed legacy/new config usage.
• What changed: added centralized Matrix DM access resolution that supports legacy fields and reuses DM allowlist for group allowlist mode when needed.
• What did NOT change (scope boundary): message parsing, delivery routing, and Matrix client lifecycle are unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes Bug: dmPolicy: "allowlist" silently drops all inbound messages for Telegram and Matrix (regression in 2026.2.23) openclaw/openclaw#25793
• Related #

User-visible / Behavior Changes

• Matrix allowlist mode now honors legacy dmPolicy/allowFrom config.
• groupPolicy: allowlist now correctly uses DM allowlist as fallback when groupAllowFrom is omitted.

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:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Bun test runner
• Model/provider: N/A
• Integration/channel (if any): Matrix extension
• Relevant config (redacted): Matrix channel with allowlist policies

Steps

1. Configure Matrix account with allowlist policy using legacy or mixed fields.
2. Start monitor and send DM/group messages from allowlisted sender.
3. Verify access decisions use expected allowlists.

Expected

• Allowlisted senders are allowed in DM/group according to configured policy.

Actual

• Previously policy resolution could fall back incorrectly and block all inbound messages.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: bun test extensions/matrix/src/matrix/monitor/index.access-config.test.ts passes.
• Edge cases checked: legacy dmPolicy mapping and group allowlist fallback behavior.
• What you did not verify: end-to-end Matrix homeserver integration run.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: revert this PR commit.
• Files/config to restore: extensions/matrix/src/matrix/monitor/index.ts.
• Known bad symptoms reviewers should watch for: Matrix DMs/groups unexpectedly blocked in allowlist mode.

Risks and Mitigations

• Risk: policy resolution could permit unintended senders if normalization is wrong.
  • Mitigation: explicit unit tests for legacy + modern field combinations and fallback behavior.