fix(sdk): keep self-targeted p tags on add/remove member builders

[santhiprakash]

Summary

buzz_sdk::build_add_member (used by buzz-cli channels add-member) builds its kind:9000 event via a plain EventBuilder::new(...).tags([h, p, role]) without calling .allow_self_tagging(). The nostr crate's EventBuilder strips any p tag matching the signer's own pubkey by default (documented behavior — allow_self_tagging() exists precisely to opt out), so a self-targeted add-member call (e.g. an owner explicitly granting themselves membership on a channel they didn't get auto-added to — see #6240) silently loses its p tag before signing.

The relay then rejects the resulting event with a confusing invalid: missing p tag — which reads as if the CLI passed a bad --pubkey, when actually the tag was present in the builder and was stripped later, invisibly, during signing.

Apply the same .allow_self_tagging() opt-in that build_message, build_forum_post, build_forum_comment, and the NIP-IA archive/unarchive builders already use, to both add- and remove-member builders in the SDK and the desktop Tauri event mirror:

• crates/buzz-sdk/src/builders.rs build_add_member / build_remove_member
• desktop/src-tauri/src/events.rs build_add_member / build_remove_member

The desktop mirror is included because the agent auto-add path in huddle/agents.rs grants the bot role to the agent's own pubkey, so the same scrub bites there. build_leave is left alone — it carries no p tag.

Related issue

Fixes #6241 (the SDK-side root cause; same code path, no new findings).

Adjacent: #6240 (the discoverer of the issue, in turn driven by the same scrub on the relay-side regeneration of kind:39002 — separate fix, separate PR).

Testing

• cargo test -p buzz-sdk --lib → 264 passed, 0 failed (4 new + 260 pre-existing). New tests cover the self-targeted path for both build_add_member and build_remove_member, asserting the p tag survives signing.
• cargo clippy -p buzz-sdk --lib --tests -- -D warnings → clean.
• cargo fmt -p buzz-sdk -- --check → clean.
• cargo fmt -p buzz-desktop -- --check → clean (verified at the desktop crate's manifest since it is not a member of the root workspace).
• Confirmed the new test catches the bug: reverted the fix locally, re-ran cargo test -p buzz-sdk --lib add_member_preserves_self_targeted, got FAILED. 0 passed; 1 failed ("self-targeted p tag must survive signing"); restored the fix and re-ran → 1 passed.

The desktop Tauri crate could not be compiled end-to-end in this environment (cmake / opus sys crate missing — pre-existing build-env gap, unrelated to the diff), but the builder change is the same one-line .allow_self_tagging() addition tested in the SDK, and the test follows the same pattern.

Diff

• crates/buzz-sdk/src/builders.rs: +57 / -2
• desktop/src-tauri/src/events.rs: +68 / -2

Signed-off-by: Santhi Prakash b.santhiprakash@gmail.com

[santhiprakash]

Closing this PR as a duplicate. The same fix (.allow_self_tagging() on build_add_member and build_remove_member plus the desktop events::build_add_member mirror) is already in flight on:

• block/buzz#3384 (shrimalmadhur, opened 2026-08-01, last updated 2026-08-14, 3 files / +190/-4). The canonical, broadest-scope PR — covers crates/buzz-sdk/src/builders.rs (add + remove), desktop/src-tauri/src/commands/project_git_workflow.rs (kind 1630/1631/1632/1633 PR status events), and desktop/src-tauri/src/events.rs (channel events mirror). 0 reviews, MERGEABLE, has been sitting in the queue for 13 days.
• block/buzz#4338 (iroiro147, 2026-08-02, +43/-2). SDK only, both add + remove. 0 reviews, MERGEABLE, 16 days untouched.
• block/buzz#4484 (Joi Ito, 2026-08-03). SDK add only. 0 reviews, 15 days untouched.

Issue block/buzz#6241 is a fresh (2026-08-18) report of the same defect already tracked in block/buzz#4326 (LarsKlawitter, 2026-08-02) which is the canonical issue #4338 references.

My pre-PR duplicate script only checks against santhiprakash's own PRs, which is why this slipped through — but four open PRs for the same .allow_self_tagging() call sites is bad queue hygiene. Closing in favor of #3384 (most comprehensive). I verified locally that #3384's diff strictly covers the scope of this PR's builders.rs change plus adds the project_git_workflow.rs path that this PR did not touch, and the desktop events.rs fix in this PR is byte-identical to #3384's. So merging #3384 makes this PR redundant.

If maintainers want a focused follow-up patch on the desktop mirror alone (without the SDK re-touch), I'm happy to send a PR against #3384.