fix(mentions): the welcome reply teaches the handle, and names the right one

[lilyshen0722]

Follow-up to #838, from Sam's review. Two changes — and one of them is a correction to a design I proposed and he was right to reject.

The gap he found

The wake fires once per member per pod, so a newcomer's second unaddressed message reaches nobody. Only a reply-threaded follow-up routes (via #703), and someone who didn't know to @mention almost certainly doesn't know to reply-thread either.

I proposed a bounded continuation window: keep routing that member's messages to the greeter for N messages or T minutes. That was wrong, for reasons worth recording:

• It cannot tell a message meant for the agent from one meant for another human. In a pod where people talk to each other, it wakes the agent on everything a newcomer says for the whole window.
• With two greeters installed it wakes both, on everything, with no notion of who owns the conversation. No principled tiebreak exists — a sign the design is wrong rather than incomplete.
• My justification was bad reasoning. I argued it was principled because fires stay bounded by (member × pod) × a constant rather than by traffic. But a bound on how many unwarranted wakes happen doesn't make any of them warranted. That's proxy-thinking — the exact failure fix(mentions): a member's first message in a pod now reaches an agent (#834) #838's own PR text warns about, committed while citing the rule.

I also overstated the problem to justify the fix. "Trained then abandoned" was wrong: message 2 getting silence is not a regression, it is what every other message in the room does today. The honest version is "helped once, then normal" — strictly better than before.

What this does instead

The gap is discoverability, not routing: the newcomer doesn't know how to address the agent. So close that, at the one moment it lands — in the reply, from the agent that just demonstrably helped them. A pinned room description already failed at this; an in-context line from a working agent won't.

The cue now ends with:

End by telling them how to reach you again: they can @commonly-support anytime, or reply directly to your message. Say it once, plainly, as the last line — not as a menu.

No new state, no routing change, degrades gracefully with multiple agents.

Naming the right handle — which is not the one the agent knows

The support agent's token carries agentName: 'hq-support', while the room renders "Commonly Support" and humans type @commonly-support. An agent asked to name its own handle answers from its token and hands the user a string they have never seen.

So the cue states the handle rather than delegating the guess. mentionHandleFor mirrors buildMentionMap's own resolution order — displayName slug first (what the UI renders, therefore what a person copies), then instanceId, then agentName.

The self-mention guard is now load-bearing

Instructing an agent to write its own handle puts that handle into a message the agent itself sent. Verified it resolves the way the guard requires: @commonly-support maps through both the instanceId key and the displayName slug to (hq-support, commonly-support) — exactly the pair isSelfMention compares — so it matches and suppresses.

That was previously an incidental property. It is now a contract, so it has three regression tests, including that a human typing the same handle still reaches the agent. Rename a display name carelessly and those tests are what catch the resulting wake loop.

Verification

• 23 service tests + 50 mention tests (3 new)
• Typecheck clean
• Mutation-verified: neutering isSelfMention fails all three new self-mention tests, so they pin real behavior rather than passing vacuously