buzz-acp: accept owner control commands with rendered mention text

[jhgaylor]

Fixes #6014, fixes #6051.

Summary

!shutdown / !cancel / !rotate were unreachable from the desktop (and mobile) UI. is_owner_control_command required all of: kind:9, content.trim() == "!rotate" exactly, and a p tag mentioning the agent. But clients render a mention as literal text in the body alongside the p tag, so:

• @Fountain Maintainer !rotate → has the p tag, but content ≠ "!rotate" → forwarded to the agent as a prompt (agent replies "not sure what !rotate should do here")
• bare !rotate → content matches, but no p tag → dropped

This was already called out in docs/welcome-kickoff-silent-failures.md §5 as mutually exclusive on every real surface.

Fix

New control_command_content_matches: a command matches when the trimmed content is the bare command, or the command is the last/first token with only mention text (@… / nostr:…, spaces allowed since display names are multi-word) on the other side. Content that does not begin with a mention, or that continues past the command (please !rotate, !rotate now), is still forwarded as an ordinary message. Owner + p-mention + kind:9 checks are unchanged.

Since the harness doesn't know its own rendered display name, @Fountain Maintainer please !rotate also matches — documented in the fn doc and README.

Related work

• Owner control commands are unsendable from Buzz Desktop: is_owner_control_command's exact-content + p-tag requirements are jointly unsatisfiable from every composer flow #6014 (@sfasching) and !rotate is unreachable from the Desktop composer — mention text breaks the exact-match gate #6051 (@jeff-theta) — both report exactly this: the exact-content and p-tag requirements are jointly unsatisfiable from the Desktop composer. This PR is the harness-side fix for both.
• feat(acp): auto-publish replies, @mention-tolerant owner commands, extra MCP servers, glm-5.3 effort table #5866 (@johnnyclawson26-aumico) — item 2 of that four-part PR also relaxes the matcher, by dropping every whitespace token that starts with @ before comparing. That handles single-word names (@zai !cancel) but, as its own doc comment notes, a multi-word display name (@Fountain Maintainer !rotate → Maintainer !rotate) still fails to match. This PR instead treats everything from the leading @/nostr: up to the trailing command as mention text, so multi-word names work, and it's scoped to just this fix so it can land independently. Happy to defer to feat(acp): auto-publish replies, @mention-tolerant owner commands, extra MCP servers, glm-5.3 effort table #5866 if that lands first — the two would conflict on is_owner_control_command.
• Owner control commands are invisible in the chat: no command affordance, and the outcome is only logged #3711 / fix(acp): acknowledge consumed owner commands in channel #3877 / feat(acp): post owner control command outcomes back into the channel #3916 — command feedback (acknowledging consumed commands in the channel). Orthogonal: they assume the command fires; this makes it fire from a real client. Owner control commands are unsendable from Buzz Desktop: is_owner_control_command's exact-content + p-tag requirements are jointly unsatisfiable from every composer flow #6014 points out the silent-prompt failure here is probably the substrate of the "commands feel invisible" experience.
• Add manual ACP session rotation command #932 — the original !rotate PR.

Test plan

• cargo test -p buzz-acp --lib owner_control_command — new owner_control_command_tolerates_rendered_mention_text covers the accepted and rejected shapes
• cargo clippy -p buzz-acp --all-targets, cargo fmt
• Manual: send @<agent> !rotate from desktop as owner; harness logs the rotate and does not reply conversationally

🤖 Generated with Claude Code