fix(cli,relay): resolve agents by verified owner

[johnmatthewtennant]

Context

buzz users get --name Honey searches relay-wide profiles and returns up to 100 identically named results without verified ownership metadata. An agent resolving “my Honey” cannot distinguish the requesting human's agent from another owner's agent, and the owned match can be excluded by the result limit. This caused the wrong Honey and Bumble pubkeys to be added to a channel.

Summary

This bug fix makes personal-agent resolution owner-aware. Callers can filter profiles by a verified owner identity before result limits are applied, and all profile results expose enough ownership context to diagnose duplicate names.

Changes

• Adds buzz users get --owner me|<hex>|<npub> for name and pubkey lookups.
• Resolves me to the NIP-OA owner identity when the CLI runs as an agent.
• Filters profiles by the relay's verified agent_owner_pubkey relationship before applying the result limit.
• Returns owner_pubkey, owner_display_name, and client-relative owned_by_me in compact and JSON output.
• Returns an empty result when no owned profile matches instead of removing the ownership constraint.
• Rejects malformed owner values instead of silently running an unscoped query; explicit null remains equivalent to no owner filter for ordinary CLI lookups.
• Rejects owner constraints on specialized channel-window, feed, and thread filters that cannot enforce author filtering.
• Scopes owner filtering and enrichment to the active community.
• Adds a partial (community_id, agent_owner_pubkey) index for owner lookups.
• Documents the safe users get --name Honey --owner me lookup.

Reviewer-reproducible examples

The relay-backed test creates two same-name agents with different verified owners, queries through the HTTP /query route, verifies only the selected owner's agent is returned with verified owner metadata, and verifies a missing owner returns [].

cargo test -p buzz-relay query_agent_owner_returns_only_verified_owner_matches --lib -- --ignored

The owner/author intersection and unsupported-specialized-filter contracts also have infrastructure-free relay tests:

cargo test -p buzz-relay agent_owner --lib

The CLI surface is visible in command help:

cargo run -q -p buzz-cli -- users get --help | grep -- --owner

      --owner <OWNER>     Filter agents by verified owner (`me`, 64-char hex, or npub)

Validation

• cargo test -p buzz-cli (252 passed)
• cargo test -p buzz-db (84 passed, 122 infrastructure tests ignored)
• cargo test -p buzz-relay --lib (owner-filter tests pass; the full local suite is blocked by unrelated Postgres pool timeouts in media/admin tests)
• cargo test -p buzz-relay query_agent_owner_returns_only_verified_owner_matches --lib -- --ignored (passed)
• cargo check --workspace --all-targets
• cargo fmt --all -- --check
• Pre-push Rust, Desktop, and Desktop Tauri suites passed
• Pre-push mobile suite could not start because flutter is not installed
• pnpm check:file-sizes (passed after rebasing onto current main)

[dophsquare]

P0 triage — merge candidate. 🐝

Confirmed the identity/access bug: buzz users get --name X searched relay-wide kind:0 profiles, capped at 100, with no ownership metadata — so an agent resolving "my Honey" couldn't distinguish the requester's agent from another owner's, and the owned match could even be excluded by the limit. That's how the wrong Honey/Bumble pubkeys got added to a channel.

The fix is the right shape: --owner (accepting me | pubkey | npub via resolve_owner) threads a verified agent_owner filter into the query before the limit applies, and copy_owner_fields surfaces owner_pubkey / owner_display_name / owned_by_me so callers can disambiguate. Using auth_tag_owner_hex() with a fallback to the client's own pubkey for the me/owned_by_me computation is sensible.

Before merge, please confirm:

1. The relay actually honors include_agent_owner / agent_owner in the filter and derives owner from a verified ownership record (not a self-asserted tag) — the whole fix hinges on the server-side verification being trustworthy.
2. owned_by_me is computed server-consistent with the filter so a spoofed profile can't set owned_by_me: true.

Code on the CLI side LGTM; the security guarantee lives in the relay half — worth a reviewer with relay context signing off on that.

[wpfleger96]

🤖 The core of this is sound and it fixes a real incident class — the owner rows come from users.agent_owner_pubkey, materialized only after cryptographic NIP-OA verification (crates/buzz-relay/src/api/mod.rs:147-216), not from self-asserted tags; the SQL is parameter-bound and community-scoped; requested authors are intersected rather than replaced; and zero owner matches fail closed on the catch-all/search paths. But there are three things I'd want fixed before this merges, the first one especially:

Blocking:

• The channel-window fast path bypasses the owner filter. In crates/buzz-relay/src/api/bridge.rs (around 1042-1060 and 1122-1137), agent_owner is rewritten into authors, but a request combining agent_owner with top_level:true is dispatched to handle_channel_window_filter() before the catch-all's empty-owner guard, and that path queries only channel/kind/cursor — it ignores authors entirely. So an owner-constrained query can return events from every author in the channel. Since the extension presents agent_owner as a generic /query filter, it needs to be enforced on every dispatch path: either reject agent_owner on the specialized filters it can't honor, or centralize the owner/author constraint so each path applies it before returning.
• No end-to-end behavioral test for the security contract. The relay test at bridge.rs:2886-2895 only checks hex parsing, the DB test at crates/buzz-db/src/user.rs:539-589 is ignored and doesn't exercise /query, and the CLI tests only cover field copying. Nothing currently proves that two same-name agents with different verified owners resolve to only the requested owner's agent, that zero matches stay empty, or that an existing authors list is intersected. Given this is an identity/access fix, please add relay-backed tests that fail without the fix and cover those cases — including the channel-window path above.
• Missing index for the new lookup. crates/buzz-db/src/user.rs:294-310 filters by (community_id, agent_owner_pubkey), but the schema only has the users PK plus the NIP-05/Okta indexes (migrations/0001_initial_schema.sql:154-181), so every owner-filtered search scans the tenant's users table. A partial index like (community_id, agent_owner_pubkey) WHERE agent_owner_pubkey IS NOT NULL plus a quick query-plan check would keep the fix from being O(all users in community).

Minor, non-blocking:

• crates/buzz-cli/src/commands/users.rs:44-55, 144-155 always sends include_agent_owner:true and serializes agent_owner:null even for plain buzz users get, which adds an extra DB lookup to every profile read and couples the whole command to the bridge extension. Omitting it unless requested would keep the default path lean.
• A one-line example of users get --name … --owner me in crates/buzz-cli/README.md would help agents actually discover the owner-aware path — it's the safe replacement for exactly the lookup that caused the incident.

Happy to re-review once the fast-path enforcement and tests are in.

[dophsquare]

Nudge on behalf of @doph — high-priority merge list. CI is green (32 checks) and the review gate is a pending re-review request to @wpfleger96. A fresh look would unblock this. 🐝