fix(desktop): admit the owner of an allowlist agent into mentions

[TheSeydiCharyyev]

Summary

relayAgentIsSharedWithUser resolves the owner in the owner-only branch, but reads respondToAllowlist literally in the allowlist branch. The harness accepts the owner in both modes — author_allowed ORs the explicit list with is_owner_or_sibling (crates/buzz-acp/src/lib.rs:249-257) — and the doc comment above it states that as the rule, not as an accident:

Both OwnerOnly and Allowlist accept the owner and same-owner siblings; Allowlist additionally accepts the explicit external pubkey list.

The two branches sit eight lines apart, so the effect is an inversion. Widening an agent's policy from owner-only to allowlist, to let one more person in, removes the agent from its own owner's picker. The agent still answers its owner, because the harness admits them, but the owner can no longer select it and a typed mention is never tagged. An allowlist with an empty array is hidden from everyone, the owner included, and nothing reports an error.

This adds the owner check to the allowlist branch. Two limits are deliberate:

• An unresolved owner still falls through to the list. On closed relays the NIP-OA attestation frequently never materializes (NIP-OA owner attestation silently discarded on closed relays when the agent is a direct relay member #4223, relay-side fix in fix(relay): record the NIP-OA owner for direct members on closed relays #5581), and admitting on absence would expose the agent to every viewer. The tests pin undefined, null and "" as denied.
• No sibling parity. is_owner_or_sibling also accepts same-owner sibling agents, but the picker's currentPubkey is the human viewer, so only the direct owner check applies.

Scope: getMentionableAgentPubkeys seeds from managedAgentPubkeys unconditionally, so agents this Desktop runs were never affected. The population this reaches is agents the viewer owns but runs elsewhere — headless agents, and agents on another machine.

The owner-only branch is left untouched. A shared helper for both branches was considered and left out: that path was rewritten last week by #6086, #6182 and #6224, and keeping the diff away from it avoids both a conflict surface and a refactor this fix does not need.

Related issue

Closes #6280.

Searched before opening. The nearest existing reports are both different:

• Desktop hides allowlisted agents owned by another user from @mention autocomplete #3125 — the viewer is in the array and is dropped by the managed-list gate from fix(desktop): prefer live agent mentions #2149. Different mechanism, and the viewer there is not the owner.
• Managed built-in agent allowlist UI diverges from persisted runtime allowlist #3030 — the saved allowlist differs from the running one. That is persistence; this is the eligibility read of a correct record.

Of the open PRs that touch agentAutocompleteEligibility.ts, none changes how the allowlist branch treats the owner. #2605 and #4204 are the only two that reach this area, and both target the cross-owner and owner-only paths.

Testing

Run in desktop on 93114c9c:

• pnpm test — 5039/5039 (5037 before, plus the two added here)
• pnpm typecheck — clean
• pnpm check — clean

Red/green on the two new tests, through the project's own runner:

• without the change — 31/33, and the two failures are exactly the new tests
• with the change — 33/33

agentAutocompleteEligibility.test.mjs now covers an owner absent from the array, an empty array, a non-owner viewer (unchanged), an unresolved owner (denied), and relayAgentCanRespondInChannel still requiring channel membership for the owner.

No screenshot: the visible effect is one entry appearing in the existing @ list, and reproducing it needs a relay plus an agent running outside Desktop. The behaviour is pinned by the unit tests instead.