pool: advertise a rendezvous only once registered, and log the pin

Issue #2 reported that /rvrelay does not govern registration. It does:
BtfAllRelays() returns vBtfMeetingRelays alone when fBtfRelayPinned, and
every relay-choosing site -- the pool's AcceptLoopFn, the node's
ThreadBtfAccept, and the dial path -- draws from it. vBtfMeetingRelays
has exactly one writer, the pin itself. A pinned pool therefore spawns
one accept thread, at the pin, and no discovered relay is registered at.

The registration the incident actually caught was not the pool's. The
"registered at" line it quotes exists only in ThreadBtfAccept, and
90.156.222.107:8434 is not a stranger's relay -- it is the third
hardcoded seed, one of the three ThreadBtfAccept picks between at random
when no pin is in force. That relay is only reachable with the pin
absent, so the binary that logged it did not have one; both the pin and
the operator-mode skip that keeps a pool out of that thread landed two
days before the observation.

What was genuinely wrong is that none of this could be read off a log.
The pool announced no successful registration at all, and retried
failures at one flat line, so "is this pool registered where its
descriptor says" had no answer. So:

  - Advertise the relay after registering at it, not before. The
    optimistic order published a meeting node we were not yet listed at,
    and a miner resolving the descriptor inside that window spent its
    dial on a relay holding no registration for us. ThreadBtfAccept has
    always ordered it this way; the pool had not.
  - Log the relay registration succeeds at, name the pin when one is in
    force, and name each discovered relay the pin excludes.
  - Escalate when a pinned relay keeps refusing: a pin has no fallback,
    so an unregistered pin means the pool is unreachable, and that now
    says so instead of scrolling past.
  - Refuse to advertise a non-pinned relay in BtfSetActiveRelay. No
    caller can reach it today, but the descriptor is the one thing a
    miner obeys, so the invariant is enforced at the sink rather than
    retrusted to every future caller.

Does not touch the registration-consumption race: the pool still gives
up its registration on each pairing and re-registers after wrap-and-push.
Moving the advertise call inside that loop does not widen the window, it
only stops the descriptor naming a relay we never reached.

0 files changed, 0 insertions, 0 deletions