fix(cli): resolve @mentions wrapped in markdown emphasis and skip code regions

[bosoud]

Fixes #2526

Problem

buzz messages send silently dropped any @mention wrapped in markdown emphasis — **@Name**, *@Name*, _@Name_ — or preceded by ( / ||. The message posted with zero p tags, exit 0, no warning, so no one was notified and no buzz-acp agent woke. Desktop's TypeScript parser (hasMention.ts) was fixed for exactly this in 0f93ef44 (#328); the Rust parser never got the equivalent, and none of the 69 existing mention tests contained an emphasis character next to an @.

Changes

Following the direction in the issue — widen the existing Rust predicates against one shared delimiter definition rather than porting the TS regex:

crates/buzz-sdk/src/mentions.rs

• New is_mention_lead(prev, prev2) — the single definition of "what may precede an @": start-of-string, ASCII whitespace, (, emphasis */_, or spoiler ||. Both extract_at_names and extract_at_mentions_with_known now use it, so the two extraction paths can no longer drift from each other.
• is_word_boundary widened to accept trailing *, _, and || (single | intentionally stays a non-boundary, matching TS), so **@Will Pfleger** matches the known multi-word name instead of falling through to a useless will token.
• Doc comments on both predicates point at hasMention.ts as the counterpart that must stay in agreement.

crates/buzz-cli/src/commands/messages.rs

• resolve_content_mentions now applies strip_code_regions before @name extraction (previously only NIP-27 URI extraction was stripped). An @name inside a fenced block or backtick span no longer fires a notification — the false-positive mirror of the reported false negative.
• buzz messages send prints a warning to stderr when the (code-stripped) content contains @mention candidates but zero mentions resolved — the independent mitigation suggested in the issue, so a zero-recipient send is no longer silent. Email addresses and @ never count as candidates, so ordinary prose does not warn.

Tests

• 10 new unit tests in buzz-sdk covering bold/italic/spoiler/paren leads, trailing emphasis on multi-word names, the single-| non-delimiter, emails inside emphasis, code-region stripping, and the deliberate _@carol_ fallback-tokenizer trade-off (the _ glues to the name in the fallback path only; the known-names path resolves it correctly — pinned in a test with a comment).
• 5 new tests in buzz-cli covering the send-pipeline regression case (**@Atlas**), code-region skipping, and the mentions_went_unresolved warning predicate.
• cargo test -p buzz-sdk -p buzz-cli, cargo clippy --all-targets, and cargo fmt all clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CqMxL1inNtU7icywZxbrGY

[SeanGearin]

Nice — this matches the direction from the triage notes, and the zero-resolved-mentions warning is a good addition. Two things worth a look:

1. Table pipes. Keeping a single | a non-boundary means a mention flush against markdown table pipes (|@Atlas|) still resolves nothing, while f9402f75 in the issue shows table mentions are expected to tag (that one only worked because of surrounding spaces). Accepting a single | on both sides is a strict superset of || and keeps the delimiter predicate single-character. Repro: extract_at_mentions_with_known("|@Atlas|status|", &["Atlas"]) — currently [], expected ["atlas"].

2. There's a third parser this doesn't reach. resolve_mention_pubkeys in crates/buzz-relay/src/workflow_sink.rs is an independent @-mention parser — its doc comment says it "defines the matching contract" for workflow-emitted kind:9 p tags, and its left-boundary check (workflow_sink.rs:102) still accepts only start-of-string / whitespace / (. Those p tags are what ACP agent wake is gated on (event_mentions_agent, buzz-acp/src/lib.rs:2656), so a workflow-generated **@Robby** emits zero p tags — the exact stalled-handoff failure mode from this issue, on a surface where the text is machine-generated. Nothing this PR needs to absorb, but the issue's "longer term the parsers should be one implementation" note actually spans three parsers, not two — worth a follow-up either way.