NIP-11 `origin` field fails the multi-tenant conformance enumeration-oracle check

[vsima]

Environment

• Relay: local build from block/buzz main (2026-07-24), buzz-relay.
• Test: crates/buzz-test-client/tests/conformance_multitenant.rs, module
  nip11_relay_info::nip11_is_not_a_cross_community_enumeration_oracle.
• Topology: two tenants (a.localhost:3100 / b.localhost:3100) on one relay,
  BUZZ_REQUIRE_AUTH_TOKEN=false, membership off.
• Re-verified at 38bf642f (main, 2026-08-05): origin is still emitted per
  host (crates/buzz-relay/src/nip11.rs:203) and a unit test now pins it
  (nip11.rs:355); the conformance module is unchanged since the run above.

What happens

The test FAILS. It asserts host A's and host B's NIP-11 documents must be
byte-identical apart from each community's own icon. They differ in exactly
one field:

left  (host A): "origin": "ws://a.localhost:3100"
right (host B): "origin": "ws://b.localhost:3100"

Everything else is identical.

Why it's (almost certainly) not a real leak

The origin field echoes the host the client itself connected to — a client
can only ever observe its own origin, never another tenant's. So it is not an
enumeration oracle for other communities. But it does make the unauthenticated
NIP-11 document vary by host, which the conformance suite flags as
defense-in-depth (NIP-11 should be tenant-agnostic).

Options (either makes the row green)

1. Omit origin from NIP-11. It's redundant — the client already knows the
   host it connected to.
2. Relax the assertion to allow origin alongside icon as a per-host
   reflection that carries no cross-tenant information.

We currently exclude this row from our local isolation gate with this note; the
other 8 implemented isolation rows pass, so the cross-tenant boundary holds.