fix(buzz-sdk): preserve self-referential p tags in add/remove member events (#4326)

[iroiro147]

Problem

A p tag whose value equals the signing key's own pubkey is dropped between the SDK builder and the wire. The builder constructs it correctly; the signed event that reaches the relay does not contain it.

This makes every self-targeted channel-membership operation impossible to express:

• buzz channels remove-member --pubkey <your own key> → relay replies 400 invalid: missing p tag
• buzz channels add-member --pubkey <your own key> --role <r> → same shape (self-add is explicitly permitted relay-side)

The relay is behaving correctly — extract_p_tag returns None because the event genuinely has no p tag. The loss happens client-side.

Impact: any actor removing itself from a channel via the CLI is blocked, which includes the legitimate "an agent/identity should relinquish standing capability in a channel it no longer belongs in" case that #2928 discusses.

Root cause

crates/buzz-sdk/src/builders.rs build_add_member (kind 9000) and build_remove_member (kind 9001) built both the ["h", …] and ["p", target] tags, but EventBuilder::sign_with_keys in nostr 0.44 strips a matching p tag before signing (it suppresses self-referential tagging by default). Other builders in the same file that share this signer==target symmetry (KIND_IA_* identity archive/unarchive, added in PR #2568) already applied .allow_self_tagging() to opt out of that strip — this path did not.

Fix

Applied .allow_self_tagging() to the build_add_member and build_remove_member return values, matching the existing NIP-IA pattern in the same crate. Two lines of production code; two new regression tests.

What was verified

• cargo check -p buzz-sdk — clean.
• cargo test -p buzz-sdk — 254/254 passing (252 baseline + 2 new regression tests).
• New tests remove_member_self_tag_survives_signing and add_member_self_tag_survives_signing sign with Keys::generate(), set the target to that same key's own pubkey hex, and assert the "p" tag survives on the wire (previously the event shipped with only the "h" tag).

Notes

The issue reporter traced the loss site to EventBuilder::sign_with_keys with high confidence and suggested either preserving self-referential p tags through signing, or failing client-side. Preserving (mirroring the NIP-IA precedent) is the minimal, protocol-legitimate fix — NIP-29 explicitly permits a user to remove or re-add themselves. buzz channels leave remains the simpler single-tag alternative but is self-only and does not cover the general "remove member X" case.

Fixes #4326

[iroiro147]

Closing this in favour of #4338, which addresses the same issue (#4326) with a 45-line change to builders.rs.

I had two open PRs against #4326 — that's my duplication, not something you should have to triage. Trimming my open-PR count on buzz so what's left is worth your time. No action needed from you.