fix(acp): answer owner DMs without an explicit @mention

[webdevtodayjason]

Closes #2747.

Problem

In a 1:1 DM with a managed agent, the agent ignored every message unless it was explicitly @-mentioned — even though a DM has exactly two participants and is addressed to the counterparty by definition. The result: agents look unresponsive to their own owner in DMs.

The mention gate (require_mention) was applied uniformly to every channel, DM included, at two levels:

• Subscription filter (config.rs): the relay-side #p filter dropped untagged events before they were ever delivered to the harness.
• match_event (filter.rs): re-checked the agent's p tag; no match → dropped.

Dropping only the subscription filter is insufficient — match_event would still drop the delivered-but-untagged DM. Both levels have to be exempted together.

Fix

Exempt the mention gate for owner-authored DM events:

• The caller computes mention_exempt = is_dm && author == owner and threads it into match_event, which skips require_mention when set.
• DM channels' subscription filter drops the #p requirement so the events are delivered in the first place.
• setup_mode opts out (keeps its own mention requirement).

Why owner-scoped, not a blanket DM exemption: exempting all DM events would let two agents in a DM trigger each other with no mention, re-creating the thread-deafness loop that #2270 is about. Scoping to the owner means the human's DM messages auto-trigger the agent while agent-to-agent DM still requires an explicit mention — preserving the anti-loop invariant. Group channels are unchanged.

Safety: DM turns are already restricted to the owner and verified siblings (#2591), so this does not open agents to third-party prompting.

Tests

• filter.rs: an owner-authored DM event with no p tag now matches (agent responds); a group-channel event with no p tag still does NOT match (gate preserved); a non-owner DM event still requires a mention.
• config.rs: the DM subscription filter drops #p; non-DM channels keep it.
• Full gate green: cargo test -p buzz-acp → 611 passed, cargo clippy -p buzz-acp --all-targets -- -D warnings → 0 warnings.

Sibling PR: the DM reply-anchor fix (#2748) is up alongside this. Related open issue: #2270 (thread deafness in group channels), a distinct but adjacent case.

Checklist

• cargo test -p buzz-acp + clippy green
• Bug fix includes regression tests
• No new unwrap() in production paths
• No new unsafe

[svndco]

Independent review — preferred ACP direction, one blocking edge case

I checked this out at 5250b55056bbee5f184e08cb91525eb3ccaebfcd and verified:

• cargo test -p buzz-acp: 602 library + 9 integration tests passed
• cargo clippy -p buzz-acp --all-targets -- -D warnings: passed
• cargo fmt --all -- --check: passed

This is safer than #2763 because the in-process mention exemption is owner-only, preserving the sibling-agent anti-loop boundary.

There is one blocking inconsistency in the dynamic-channel path: is_dm_channel() deliberately returns true when metadata resolution fails (fail-closed for the author gate), but lines 1987–1988 reuse that value to remove the relay #p filter, and line 2197 reuses it to exempt an owner event from require_mention. A transient metadata failure for a newly joined non-DM channel therefore makes that channel behave like a DM for mention matching, contradicting the stated “unknown types keep the mention filter” behavior used at startup.

Please split the two verdicts: keep unknown => DM for author authorization, but require positive channel_type == "dm" metadata for mention-filter bypass. Add a regression test proving unresolved channel type retains require_mention. With that adjustment, this is the ACP PR I would keep; #2763 can close as the duplicate.

[webdevtodayjason]

Good catch, thanks for taking the time to actually check it out and run the gates. You're right about the dynamic path reusing the fail-closed value. Fixed in b4292e6 (new commit, didn't force push).

I split it into two checks. is_dm_channel() stays exactly as it was, fail-closed, and only gates author auth. Added is_dm_channel_confirmed() which needs channel_type == "dm" to actually resolve, and that's what gates the #p filter removal and the require_mention exemption now. Both come from one resolve_dm_verdict() call per event so they can't drift apart. The dynamic path now matches what startup was already doing with unknown types.

Added the regression test you asked for (unresolved type keeps require_mention and stays fail-closed on auth) plus coverage for the positive DM case and a resolved non-DM.

cargo test -p buzz-acp is at 614 passing, clippy -D warnings and fmt clean.