buzz-acp: BUZZ_AUTH_TAG never reaches a headless agent's kind:0 profile — NIP-OA sibling admission silently fails until a manual set-profile

**Describe the bug**

For a headless / hand-provisioned agent, setting `BUZZ_AUTH_TAG` in the agent's environment and restarting buzz-acp is **not sufficient** to make NIP-OA sibling admission work — and nothing tells you why.

The sibling gate (`author_allowed → is_owner_or_sibling → check_sibling_via_profile`) verifies the owner attestation by reading the **author's stored kind:0 profile** on the relay. But `BUZZ_AUTH_TAG` only injects the tag into events the client happens to sign, and **buzz-acp never publishes or refreshes a kind:0 at startup**. So the tag sits in the environment, the relay keeps serving the old un-tagged profile, and every sibling-authored event is silently dropped by the recipient's author gate. From the operator's seat this is indistinguishable from an idle agent.

**Steps to reproduce**

1. Two agents, same owner, hand-minted identities (no desktop involvement), both relay members, both `respond_to=owner-only`.
2. Owner computes valid NIP-OA tags (`buzz-sdk` `compute_auth_tag` example) for both agent pubkeys; each agent gets `BUZZ_AUTH_TAG=` in its env; both processes restarted. Startup even logs `owner resolved from BUZZ_AUTH_TAG: ` — which reads like success.
3. Agent A mentions agent B (kind 9, correct `p` tag, verified in the relay's events table). **B never fires a turn.** No log line on either side.
4. Query B's view of A's kind:0: still the pre-tag profile from initial provisioning.
5. Workaround that fixes it: from A's environment, run `buzz users set-profile --name --about ` — the CLI injects the auth tag into the freshly signed kind:0. Restart B (see #5450 — the negative sibling verdict is cached). Sibling admission then works immediately; measured end-to-end at 47 s mention→turn.

**Expected behavior**

Setting `BUZZ_AUTH_TAG` and restarting the agent should be sufficient for sibling admission (or the startup log should say the profile still lacks the tag), rather than requiring an undocumented manual `set-profile`.

**Version and platform**

- Buzz version: relay + buzz-acp built from rev `96ae141` (2026-08-06)
- OS: relay in Docker on Debian 13 (x86_64); agents on Debian (aarch64 and x86_64), self-hosted single-community relay, `require_relay_membership=true`, `allow_nip_oa_auth=true`

**Logs / additional context**

Startup logs `owner resolved from BUZZ_AUTH_TAG: ` and nothing else; the drop is silent on both sides. Relay's stored kind:0 for the sender (read via psql) confirmed tag-less until the manual `set-profile`, and tag-carrying immediately after.

Suggested fix: at buzz-acp startup, when `BUZZ_AUTH_TAG` is set, fetch own kind:0 from the relay; if absent or missing/mismatching the `auth` tag, republish the profile (preserving existing content fields). That makes the env var self-sufficient, matches what the startup log already implies, and costs one read + at most one write per boot. Docs alternative if the republish is unwanted: the `BUZZ_AUTH_TAG` documentation should state that a headless agent must run `buzz users set-profile` once after the tag is set or changed.

Related: #5450 (the cached negative sibling verdict makes this worse — even after the profile is fixed, the recipient must restart) and #4223 (different layer: relay-side attestation materialization; this issue is client-side publication).

Happy to send the buzz-acp startup-republish patch as a DCO-signed PR if the approach sounds right to maintainers.