fix(acp): honor persona thread_replies in prompt builder

[santhiprakash]

Summary

Fixes #4699.

thread_replies was parsed and merged in buzz-persona but never read in buzz-acp. The harness always injected an IMPORTANT: directive forcing --reply-to <event_id> for new top-level channel mentions, so a persona with thread_replies: false still opened a thread.

This PR plumbs the resolved flag through Config / PromptContext / FormatPromptArgs with a default of true (per PERSONA_PACK_SPEC.md). When thread_replies is false, format_prompt skips the forced reply anchor for new top-level channel mentions. Existing thread and DM anchors continue to work.

What changed

• Added --thread-replies / BUZZ_ACP_THREAD_REPLIES to CliArgs and Config.
• Threaded the value through PromptContext and FormatPromptArgs.
• Skipped resolve_reply_anchor for human-facing top-level channel turns when thread_replies == false.
• Added queue.rs unit tests covering:
  • top-level suppression when thread_replies: false
  • existing threads still anchored when thread_replies: false
  • DM replies still anchored when thread_replies: false

Verification

• just fmt-check and just clippy pass.
• just test-unit passes (including new buzz-acp tests).

[santhiprakash]

Closing this for now — not because the underlying issue is invalid, but because the branch now conflicts with recent ACP rework that landed in the same files, and I can't give the rebase the verification it deserves from here.

What conflicted

• Revert "fix(acp): reject unattended permission requests" #5323 (Revert "fix(acp): reject unattended permission requests") and Reduce repeated ACP session context #5423 (Reduce repeated ACP session context) both reworked crates/buzz-acp/{config,lib,pool,queue}.rs — the same files this PR touches.
• The conflicts are mechanical/additive: the new StandingContext struct + standing_context_sent field sit right alongside this PR's thread_replies field, and the two features are orthogonal. But the behavioral suppression logic (skipping the forced --reply-to anchor in resolve_reply_anchor for top-level channel turns) needs to be re-validated against the new standing-context dispatch model from Reduce repeated ACP session context #5423, which I can't cargo test -p buzz-acp from this environment.

The underlying bug is still real

#4699 is still open and still reproducible on main: append_new_thread_reply_instruction() still unconditionally appends the IMPORTANT: --reply-to <event_id> directive (queue.rs ~L1154-1178), and resolve_reply_anchor is still called unconditionally for non-DM turns (~L1529). So a persona with thread_replies: false still opens a thread for every top-level channel message.

Next step

I'll re-file this as a fresh focused PR against current main — re-applied on top of the StandingContext work, with the behavioral logic re-checked and the unit tests updated — from a machine that can run the buzz-acp test suite. Happy to reopen here if a maintainer would rather pick it up; the queue.rs tests in this branch describe the intended behavior.