Shared Mini-hosted agents still not mentionable on 0.5.6 — no autocomplete chip, no p tag, agent never wakes

## Summary

On **Buzz Desktop 0.5.6**, an agent hosted on another machine (Mac Mini), owned by identity A, with `respond_to: anyone` and real channel membership, still **does not appear as a mention chip** for identity B on a different machine.

Without a resolved mention, outbound kind-9 messages carry only the channel `h` tag — **no `p` tag** for the agent’s pubkey — so the agent harness never routes the message and the agent never wakes.

We upgraded both the agent host and the client to **0.5.6** (including `fix(desktop): allow shared agent mentions` #4913) **before** retesting. The failure still reproduces.

This looks like the residual half of the cross-owner mention problem: eligibility may allow shared agents, but discovery / candidate admission still fails for standard desktop-managed agents so non-owners never get a chip or a `p` tag.

## Environment

| Item | Value |
|---|---|
| Desktop (agent host) | **0.5.6** (Mac Mini, always-on) |
| Desktop (human client) | **0.5.6** (separate Mac) |
| Relay | Self-hosted (`wss://…ts.net`), private tailnet |
| Agent host identity | A (owner of the agents) |
| Mentioning identity | B (channel member, **not** agent owner) |
| Agent | e.g. display name `Larry`, role `bot` in shared channel |
| Agent config | `respond_to: anyone` (confirmed on disk / harness / kind 30177) |
| Agent membership | Channel member, role `bot` |

## Expected behavior

1. Identity B types `@` in a shared stream channel where the agent is a bot member.
2. The agent appears in autocomplete as a **highlighted mention chip** (same as a local managed agent).
3. Selecting it (or resolving the mention) produces an outbound kind-9 with a **`p` tag** for the agent’s pubkey.
4. The agent harness wakes and replies.

## Actual behavior

1. Identity B types `@`.
2. **Agent does not appear** as a mention pill/chip in the picker.
3. Free-typing `@Larry` / `@larry` sends **plain text** that looks like a mention in the UI timeline but has **no `p` tag** for the agent.
4. Agent is completely silent (never starts a turn — not the 👀/💬-then-kind-5 abort path).
5. Identity A (owner on the Mini) can mention the same agent normally; replies work.

Agent self-diagnosis on a silent message (paraphrased from live chat):

> Human posted `@larry …`. That event has no `p` tag for my pubkey — only the channel `h` tag. Without a resolved `p` mention, the harness does not route the message into my session.

When a later message **did** carry a proper `p` tag, the agent woke immediately.

## Reproduction steps

1. Machine A (always-on): create/run a managed agent (`respond_to: anyone`), add it as a **bot** member of a shared channel.
2. Machine B: join the same community/relay and channel as a normal human member (does **not** manage the agent locally).
3. From B, open the channel composer and type `@`.
4. Observe: agent name is **absent** from autocomplete (no chip).
5. From B, send a message containing free-typed `@AgentName are you there?` without selecting from the picker.
6. On the relay, inspect the kind-9 tags (or have the agent report whether it received a mention).
7. Confirm: **no `p` tag** for the agent pubkey; agent does not wake.
8. From A (owner), `@AgentName` via autocomplete → agent replies.

### Relay verification (optional but decisive)

```sql
select left(replace(content, E'\n', ' '), 60) || ' p->' ||
coalesce((
select string_agg(substring(t->>1 for 8), ',')
from jsonb_array_elements(tags) t where t->>0 = 'p'
), 'NONE')
from events
where kind = 9
order by created_at desc
limit 15;

• Silent “@Agent” from B → p->NONE (or no agent pubkey).
• Working mention from A → p->.

Impact

Breaks the “always-on shared team agents on a Mini” model:

• Teammates can see agent messages but cannot command them via @mention.
• Free-typed @Name looks like a mention in the UI but is not deliverable to the harness.
• Multi-human → Mini-agent workflows fail silently (no error in the app).

Why we believe 0.5.6 did not fully fix this

0.5.6 ships #4913 (https://github.com/block/buzz/pull/4913) (allow shared agent mentions), which admits relay-discovered agents when policy allows the viewer.

This matches the open analysis in:

• #3776 (https://github.com/block/buzz/issues/3776) — cross-owner mentions + eligibility reading a kind nothing publishes
• #4776 (https://github.com/block/buzz/issues/4776) — desktop drops agents it doesn’t manage locally
• #4716 (https://github.com/block/buzz/pull/4716) — open PR to source discovery from kind 30177 (not merged as of this report)

If #4913 was meant to fully close this for desktop-managed shared agents, please treat this as a regression / incomplete fix on 0.5.6. If #4913 only covers a subset (e.g. agents that already publish 10100), please document that and keep the 30177 discovery gap as a blocker for team Mini hosts.

What is not the issue (ruled out)

┌──────────────────────────────────────────────────────────┬────────────────────────────────────────────────────────────────────────────────────┐
│ Check │ Result │
├──────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┤
│ Agent offline / not running │ ❌ Agent answers owner mentions fine │
├──────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┤
│ Wrong respond_to │ ❌ anyone on instance + harness │
├──────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┤
│ Agent not in channel │ ❌ Bot member confirmed │
├──────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┤
│ Case sensitivity alone │ ❌ Matcher is case-insensitive in source; root failure is “no chip / no candidate” │
├──────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┤
│ Harness permission abort (👀 then 💬 then kind-5 delete) │ ❌ This case is no wake at all (missing p) │
├──────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┤
│ Client still on 0.5.5 │ ❌ Both host and client on 0.5.6 before retest │
└──────────────────────────────────────────────────────────┴────────────────────────────────────────────────────────────────────────────────────┘

Requested fix

1. Non-owner channel members must be able to @-mention a channel bot agent they don’t manage locally when policy allows (respond_to: anyone or allowlist including them).
2. That mention must show as a chip in autocomplete and emit a p tag on send.
3. Prefer sourcing mentionable agents from events the product actually publishes (kind 30177 and/or channel membership + profile), not only kind 10100 if nothing publishes it.
4. Ideally: free-typed @DisplayName (case-insensitive) also resolves when the agent is a channel member and invocable — but autocomplete chip + p tag is the minimum.

Acceptance criteria

• [ ] From identity B on a second machine, @ lists the Mini-hosted agent as a selectable chip in a shared channel.
• [ ] Selecting the chip and sending produces a kind-9 with p = agent pubkey.
• [ ] Agent wakes and replies without requiring the owner to re-@mention.
• [ ] Free-typed @agentname either resolves the same way or the UI clearly shows it was not resolved (no silent plain-text “fake mention”).

Related

• #3776
• #4776
• #4913 (shipped in desktop-v0.5.6)
• #4716 (open discovery fix)
• Release: https://github.com/block/buzz/releases/tag/desktop-v0.5.6