fix(autorelay): track the disconnected peer cleanup goroutine - #3522

Problem

relayFinder.background() starts cleanupDisconnectedPeers with a bare go, unlike every other goroutine it spawns, which all go through rf.refCount. Stop() cancels the context and then waits on rf.refCount, so it can return while cleanupDisconnectedPeers is still running. Two concrete consequences:

1. Stale metrics. Stop() calls resetMetrics() after refCount.Wait() returns. The surviving goroutine can call metricsTracer.ReservationEnded(1) afterwards, leaving a non-zero gauge on a stopped relay finder.
2. Cross-run state corruption. Start()/Stop() are restartable on the same relayFinder and rf.relays is shared across runs, so a goroutine left over from run N can delete(rf.relays, evt.Peer) a reservation that run N+1 just made.

Fix

Track it with rf.refCount.Go, matching its sibling goroutines. This cannot make Stop() hang. cleanupDisconnectedPeers only blocks on ctx.Done() and its subscription channel, and every send it makes - notifyMaybeConnectToRelay, notifyMaybeNeedNewCandidates, notifyRelayReservationUpdated - is a non-blocking select/default. The refCount.Add also happens while the counter is already non-zero (background itself is tracked), so it is the documented-safe WaitGroup pattern already used at lines 170 and 174.

Test

TestStopWaitsForCleanupDisconnectedPeers wraps the event bus so the cleanup goroutine's subscription Close() blocks on a channel the test controls. That converts the shutdown race into a deterministic assertion: once the goroutine is parked in Close(), Stop() must not have returned.

• Without the fix: fails on every run, immediately.
• With the fix: passes, including under -race.