buzz_sdk::build_add_member fails for self-targeted grants (missing p tag)

## 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 block/buzz#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.

## Repro

```
buzz channels add-member --channel --pubkey --role admin
# → {"error":"relay_error","message":"relay error 400: invalid: missing p tag","retryable":false}
```

The identical call with a different (non-self) target pubkey succeeds normally.

## Suggested fix

In `buzz_sdk::build_add_member` (and any other builder in `buzz-sdk` that constructs a structural/administrative `p` tag rather than a social "mention"), call `.allow_self_tagging()` before signing, since these aren't NIP-10-style mention tags and self-targeting is a legitimate, expected case.

Found while working around block/buzz#6240.

Start at `buzz_sdk::build_add_member` and trace the `EventBuilder::new(...).tags([h, p, role])` path used by `buzz-cli channels add-member`; reproduce the self-targeted command from the issue. The fix is done when the self-targeted event retains its `p` tag and the relay accepts it, while non-self targets continue to work.

Written by the indexing model from the issue text.