[ContextVM-org]

Problem

A client handed only a coordinator's pubkey can learn where to reach it from
exactly one place: the coordinator's own NIP-65 relay list (kind 10002). The
SDK's discoverability publication never delivered it. Observed in the wild
(cordn-server, 2026-10-08):

WARN contextvm_sdk::transport::server::announcement: Failed to publish relay list
     error=Transport error: relay not found
INFO contextvm_sdk::transport::server::announcement: Discoverability event publishing complete

Three root causes, all in the SDK:

1. RelayNotFound on every publish with default bootstrap relays.
   publish_to_discoverability_relays merges the advertised relays with
   DEFAULT_BOOTSTRAP_RELAY_URLS and hands the set to send_event_builder_to,
   but nostr-relay-pool rejects the whole batch when any URL is not a member
   of the main pool (send_event_to → Error::RelayNotFound) — and the
   bootstrap relays are never added to that pool. The publish failed 100% of
   the time, not just during a startup race.
2. Total refusal was reported as success. send_event_to returns Ok with
   an empty success set when every relay refuses, so the old code logged
   "Published relay list" even when nothing landed anywhere.
3. No socket wait, no retry, refusal reasons swallowed. The publish fired
   the instant start() called the non-blocking connect(), one-shot.

Change

• RelayPool::publish_to now honors its documented contract: it delivers
  through a short-lived dedicated connection to exactly the target relays
  (they need not be pool members — same pattern as the TS SDK's
  publishEventToRelayUrls). It waits up to 10 s for the first socket before
  sending, logs each refusing relay's own reason (e.g. blocked: event kind 0 is not allowed), and errors when no relay accepted the event.
• The announcement manager retries rounds with no acceptance every 30 s for up
  to 5 minutes, then gives up and says so. The two events publish
  concurrently with independent retry budgets, so an always-refusing kind 0
  can never delay the discovery-critical kind 10002.
• The spawn/test duplication in spawn_publish_discoverability collapses into
  one shared publish path.
• The rmcp integration example now asserts kind 10002 and kind 0 are served by
  the relay in both relay modes (its server config sets profile_metadata, so
  kind 0 is actually published), covering the real delivery path that unit
  tests can't reach through MockRelayPool.

Deliberately out of scope (app-level policy, and beyond TS parity): periodic
refresh, per-relay backoff ladders, and new bootstrap relays. Consumers that
need a refresh loop can re-publish on their own schedule; the SDK owns reliable
publication at startup.

Notes

• Behavior change: publish_to no longer reuses the main pool's connections —
  it opens and tears down a dedicated connection per call. Failure logs gain
  the kind suffix (Failed to publish relay list (kind 10002)).
• A timed-out retry round drops the temp pool without disconnect()
  (ponytail: comment in publish_with_retry); nostr-sdk relays tear down
  with their handles. Revisit only on leak reports.

Verification

• New tests: retry-until-accepted (2 injected failures → exactly 3 rounds),
  give-up-after-deadline (bounded retries, loud error), and
  relay_list_publish_does_not_wait_for_a_stuck_profile — the last one
  fails on its own assertion when the publishes are serialized again
  (checked by breaking the fix on purpose).
• Quality gate: fmt clean, clippy --all --all-features --all-targets -D warnings clean, cargo test --all --all-features 1127 passed / 0 failed,
  --no-default-features 729 passed, cargo doc 0 warnings.
• Live smoke path: cargo run --example rmcp_integration_test --features rmcp -- relay-rmcp <relay> now verifies the 10002 + kind 0 land on the relay.