fix(acp): follow threads the agent participates in (#2270)

[brocoppler]

What this solves

Fixes #2270 (independently re-reported this morning as #2332). A mention-gated agent (SubscribeMode::Mentions, the default) goes deaf in threads it has joined: once it replies, untagged follow-ups like "yes, go ahead" are never seen unless the human re-tags the agent on every message. The gate exists at two levels — the relay REQ's #p clause never delivers the reply, and match_event's mention re-check would drop it anyway.

How it works

Participation opens a thread; inactivity closes it.

• thread_follow.rs (new): per-channel set of followed NIP-10 thread roots with a sliding inactivity TTL (default 24h, --thread-follow-ttl-secs / BUZZ_ACP_THREAD_FOLLOW_TTL_SECS) and a hard per-channel cap (64, least-recently-active evicted). Participation is recorded at dispatch time: the batch's thread root, or the triggering event id when the agent's reply is about to start a new thread (mirrors resolve_reply_anchor — this is the exact repro case in [Bug] buzz-acp agents go deaf in threads they've joined unless re-mentioned. #2270). Admitted followed-thread events refresh the TTL, so live conversations keep sliding.
• Relay gate: REQ construction is extracted into build_req_filters(), which emits a second filter clause — same #h/kinds/since, plus #e limited to followed roots — only when the base clause is mention-gated. The mention gate stays intact for everything else; no channel firehose. Subscription updates reuse the existing per-channel sub-id replacement path and replay from last_seen minus skew, so replies landing during the update window are recovered. Resubscribes fire only on thread join/expiry, not per message, staying inside the pacing envelope from fix(acp): honor relay rate limits and pace resubscribes on bad links #2199/fix(acp): pace relay observer frames (6/s + 90/min, zero burst) #2217.
• Local gate: match_event takes the followed set and admits an unmentioned event only when its thread root is followed. Channel scope, kinds, and evalexpr filters still apply — following relaxes only the mention check.
• Lifecycle: channel unsubscribe clears its follow state; --no-follow-threads (BUZZ_ACP_NO_FOLLOW_THREADS) restores the previous strict-mention behavior. State is in-memory, matching the harness's existing recovery semantics (after restart, a fresh mention re-joins a thread).

Testing

• 13 new unit tests: follow-state lifecycle (record/touch/TTL/cap/eviction/dirty-tracking/channel isolation), match_event followed-thread admission (admits followed, ignores unfollowed and top-level, relaxes only the mention gate), and build_req_filters clause construction (base-only, roots-ignored-without-mention-gate, two-clause shape).
• Full cargo test -p buzz-acp: 583 passed, 0 failed. cargo clippy --all-targets --all-features clean, cargo fmt clean.
• Verified end-to-end against a live local relay (Claude Code behind claude-code-acp): mention answered in-thread; untagged human follow-up in the followed thread answered (~15s, p tags empty); untagged replies in unfollowed threads silent; agent-authored unmentioned replies suppressed under both owner-only and --respond-to anyone (see review thread for transcripts). Can add these as a buzz-test-client integration test on request.

Follow-up candidates (out of scope here)

• Surfacing followed-thread state to the desktop (ties into feat(desktop): auto-continue agent loop on untagged thread reply #1654's auto-continue UX).
• Optionally persisting follow state across harness restarts via the pending-turn ledger machinery from feat(buzz-acp): durable pending-turn ledger for agent auto-resume after app restart #2177.

🤖 Generated with Claude Code

[BradGroux]

Blocking evidence against current head 930c0ef33262d6f15772ff9d253e81b3853730e7: the implementation does not preserve #2270's stated anti-loop invariant.

Control-flow evidence

The current head does these three things in sequence:

1. author_allowed explicitly allows same-owner sibling agents in both OwnerOnly and Allowlist modes.
2. The inbound path applies that author gate, then passes the channel's followed roots into match_event (lib.rs).
3. match_event bypasses require_mention whenever the event's root is followed. It does not distinguish a human author from an agent author on that followed-only path.

Once sibling agents A and B have both participated in one thread, an unmentioned reply from B can therefore wake A. A's reply can wake B through the same rule. That is the agent-to-agent loop #2270 explicitly says must remain impossible.

This is not covered by the new tests. They prove that a generic unmentioned event in a followed root is admitted, but do not exercise author identity or two participating agents.

Required correction

Please keep explicit agent mentions working, but reject agent-authored, unmentioned events that are admitted only because their root is followed. If the proposed follow_thread_authors = "humans" | "all" policy is retained, the safe default needs to be humans.

Regression coverage should include:

• human unmentioned reply in a followed root → admitted;
• sibling-agent unmentioned reply in that root → dropped;
• external agent unmentioned reply in RespondTo::Anyone → dropped;
• explicitly mentioned agent-authored reply → existing configured behavior preserved;
• two agents following the same root cannot auto-continue each other.

The PR description also states that this has not been exercised against a live relay. Please add the end-to-end relay case before treating #2270/#2332 as resolved: mention agent → agent replies → human sends an untagged thread reply → harness receives exactly one new turn.

Separate timing evidence for successful explicit mentions is now tracked in #2386; this comment is about correctness and loop safety, not model latency.

[brocoppler]

The loop was real: ignore_self blocks self-loops and the author gate blocks strangers, but same-owner siblings pass the gate by design, and the follow bypass in match_event didn't check author kind. Fixed in 6318ba4:

• match_event reports admission basis (MatchedRule.admitted_via_follow) — follow-bypass admissions are distinguishable from mention matches at the call site.
• New --follow-thread-authors <humans|all> (BUZZ_ACP_FOLLOW_THREAD_AUTHORS), default humans: follow-only admissions from agent authors are suppressed. Explicit mentions never take this path. Suppression runs before the TTL refresh, so agent chatter can't keep a thread alive.
• Agenthood classification reuses the existing NIP-OA heuristic (profile_event_is_agent, now pub(crate)) via a cached kind:0 lookup that runs only on the follow-admitted path. It classifies by agenthood, not gate mode, so it covers external agents under RespondTo::Anyone. Unknown/unfetchable identities classify as human (fail open, matching turn_is_human_facing); the security gate remains author_allowed.

Regression coverage per your list: human unmentioned reply in a followed root admitted; agent-authored unmentioned reply dropped (siblings and external-under-Anyone, both via the agenthood classification); explicitly mentioned agent-authored replies unaffected; all as explicit opt-in; two-agent auto-continue cannot start from either side at the decision layer. 589 tests pass, clippy/fmt clean.

Live-relay run (local relay, this branch, Claude Code behind claude-code-acp, second identity carrying the NIP-OA auth-tag shape):

1. Mention → in-thread reply → untagged human follow-up (p tags []) → exactly one new turn, ~15s. Untagged replies in unfollowed threads: no turn.
2. Agent-authored unmentioned reply in a followed root → no turn. Under default owner-only the author gate drops it first (its attestation fails signature verification). Under --respond-to anyone — author gate admits everyone, this guard is the only defense — the harness logs followed-thread admission suppressed for agent author and fires no turn.

human:  @Scout final guard test: 7+7? Just the number.      ← dispatched, thread followed
agent2: unmentioned agent reply under respond-to anyone     ← suppressed, no turn

human: @Scout round 3: what is 2+2? …    → agent: "4"
human: thanks - now 3+3? (not tagging)   → agent: "6"   (p tags: [])

Observed turn latency (~15–30s) matches #2386. The PR description's "not yet exercised against a live relay" line is updated. Can add these scenarios as a buzz-test-client integration test if wanted.