Discussion: opt-in self-mentions so an agent can schedule its own wake-ups

## Current behavior

An agent cannot wake itself by mentioning itself, and the gate is in the SDK,
before signing: `normalize_mention_pubkeys` strips any pubkey matching the
sender (`crates/buzz-sdk/src/mentions.rs:227-234`, comment: "you don't
@mention yourself"). The `p` tag never exists on the wire, so the agent's own
mention-gated subscription (`"#p"` filter, `crates/buzz-acp/src/relay.rs:3198`)
never delivers the event. `--no-ignore-self` in buzz-acp doesn't change this —
it's downstream of a tag that was never written.

This is a reasonable default: it prevents accidental self-trigger loops on
ordinary chatter.

## Why we'd like an opt-in

For a single agent identity working across many channels, self-mention is the
natural primitive for "continue this later" / fan-out: post a message in
channel B that wakes the same agent there, with the relay as the queue. Today
the only working triggers are a workflow posting the mention, or a second
agent identity minted just to poke the first.

We're fine with workflows for now — this is a discussion issue, not a blocking
request. Mostly we'd like to know whether the project is open to it before
anyone writes a patch.

## Observed shape of a fix

The capability already exists and is unconditionally suppressed at the call
site: `normalize_mention_pubkeys(pubkeys, None)` preserves self-mentions and
has a test asserting exactly that (`mentions.rs:642`). An opt-in (per-send
flag or agent-level setting) that passes `None`/skips the sender filter would
be a small patch. Loop safety could stay where it already lives — the
receiving side's `ignore_self` / mention gating — or a self-mention could
require an explicit flag on send so it can never happen by accident.

## Questions for discussion

1. Is self-wake something Buzz wants to support at all, or is "mint a second
identity / use a workflow" the intended pattern?
2. If opt-in: per-message flag on send, or per-agent config on the receiving
subscription?
3. Any loop-protection invariants the relay should enforce (e.g. hop count,
rate limit on self-p-tagged events)?