fix(desktop): let channel-member agents be mentioned - #5

Resolves the desktop agent-mention conflicts from upstream block#6338
("Fix cross-owner relay agent mentions in owner-only builds"), which
removed the owner-only gate from mention admission that this fork had
also been carrying.

- agentAutocompleteEligibility: take upstream's removal of the
  ownerOnly/isManagedAgent/ownerPubkey gate; keep the fork's
  lenient channel-member branch (#5) and its directoryAgentPubkeys
  input, which upstream's change does not cover.
- agentMentionRevalidation: same — drop the owner-profile proof fetch,
  keep the roster fetch that the member branch depends on.
- useMentions: keep the fork's per-community relay URL (#4), drop the
  owner-only query.
- MembersSidebar: keep the fork's MembersSidebarAddMemberRows split and
  delete upstream's duplicate AddMemberSearchResultRow.tsx.
- relayReconnectReplay.test.mjs: upstream's new coupling guard reads the
  drift literal from ingest.rs; this fork hoists it into buzz-core for
  buzz-waker, so point the guard at the real definition.

Validated: desktop tsc, 5438 desktop tests, biome, px/file-size guards,
cargo fmt, cargo check (workspace + Tauri, all targets), 2781 Tauri lib
tests.

Signed-off-by: Junchao Yan <[email protected]>

…ction (block#8606)

Follow-up to block#8575.

## Problem

Today a kind:9000 is stored first and the membership write runs
afterwards, on its own. If that write fails, the relay logs it and still
returns an accepted OK. A resend of the same event then returns
`duplicate:`, so the person is never added. This is the
catch-log-and-accept failure that Review-Proven Rules #1 and #5
describe.

## Change

kind:9000 now uses the same atomic path as kind:9002
(`persisted_atomically` in ingest).

- **`buzz-db`:** new `put_members_with_event`, which runs one
transaction:
1. Take the channel's membership lock, before the event insert, the TTL
lock and the channel row. This matches the order the other membership
writers use, so it adds no new lock cycle.
2. Store the event. If it's already stored, roll back and return
`Duplicate`.
3. Run the existing `put_members` decisions and upsert. These now live
in a shared `put_members_on` step on the transaction.
  4. Commit.
- **Failure:** nothing is stored and the client gets an `error:`
rejection, so it can resend the same event and have it applied.
- **Everyone refused:** if the decisions under the lock refuse every
person, nothing is stored and the event is rejected with the same text
validation gives. Before, a single-person add refused at that point was
accepted with an empty message.
- **After commit:** the live effects stay as they were. They're
best-effort and read the committed state: cache invalidation,
`member_joined` notices, member-added notifications and 39002 discovery.
- **`NOSTR.md`:** now says a failed kind:9000 can be resent as is.

## What got simpler

- kind:9000 no longer has its own store-then-apply path in ingest. It
shares the atomic branch with 9002 and workflow deletion.
- `apply_put_user`'s "write failed, report it as a per-person rejection
inside an accepted OK" branch is gone.
- The `Db::put_members` wrapper is deleted. Its only caller was the
kind:9000 path.

## Identified debt (not in this PR)

kind:9001 (remove), 9021 (join) and 9022 (leave) have the same gap. Each
stores the event, then runs the membership write in
`handle_side_effects`, and a failure is only logged. kind:9008 and 9005
follow the same store-then-apply pattern. These can move onto the same
atomic shape in a follow-up.

## Tests

- `failed_put_user_stores_nothing` (relay, Postgres): a test trigger
fails the second person's row in a two-person add, after the event row
and the first person were already written in the same transaction. It
checks:
  - Both the send and a resend are rejected with `error:`.
- No kind:9000 is stored, nobody is added, and no `member_joined` notice
is posted.
  - With the trigger dropped, the same signed event adds both people.
  - One more resend returns `duplicate:` and posts no second notice.
- `put_members_with_event_stores_the_event_with_its_writes` (buzz-db):
checks the three outcomes:
  - Refused: nothing is stored.
  - Applied: the event is stored and the person is written.
  - Duplicate: the roster is left alone.
- `put_user_refused_under_the_lock_stores_nothing` (relay, Postgres): a
test trigger removes the sender from a private channel inside the write
transaction, so validation passes and the decision under the lock
refuses. For a single add and a batch, it checks the `invalid:`
rejection, that nothing is stored and no notice is posted, and that the
same event applies once the trigger is gone.
- Mutation checks, run in Blox gates:
- At `d18e88fd`: committing the refused event fails the buzz-db test;
applying a duplicate fails the first two tests; storing the event in its
own transaction fails the first two tests.
- At `3b106623`: turning the refusal under the lock into `error:` fails
the new refusal test, and so does committing the refused event.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Signed-off-by: Luke Tornquist <[email protected]>
Co-authored-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz>
Co-authored-by: Claude Opus 5.5 <[email protected]>