rendezvous: bound the wait for a dial, so a dead path is noticed

[Bitflash-sh]

Fixes the node going deaf after a while — the thing behind the memory note "relay caído não é redescoberto em runtime", except the relay is not what dies.

What happens

A node registers at a relay and waits to be dialled. That wait had no bound, and ConnectTo() clears the socket timeout deliberately: a registration is idle by design and may sit for a long time.

What it cannot survive is the path dying with neither end saying so — the ordinary case, not the exotic one. A NAT drops the idle mapping, a relay restarts, a route changes. No FIN arrives, nothing becomes readable, recv() never returns. The thread stays alive and asleep, so ThreadBtfAccept never reaches the continue that would register again.

if (!btf::RvServiceWaitPaired(rv))   // ← parked here forever
{
    btf::RvClose(rv);
    continue;                         // ← never reached
}

The node is unreachable and every outward sign says it is healthy.

Caught in production on the bootstrap seed: 27 minutes without a block, eight behind the network, the relay reachable throughout, a restart fixing it instantly. Nothing in the log marked the moment it went deaf — the same shape as #29, #30, #42 and #46.

Keepalive does not fix this

It was my first attempt and it is measured, not assumed. With probes every 5s and a 2-probe limit, a socket whose replies were being dropped was still ESTAB after four minutes, probe counter stuck at zero:

   30s  timer:(keepalive,,0)
   60s  timer:(keepalive,644ms,0)
  ...
  240s  timer:(keepalive,1.608sec,0)
  VERDICT: still blocked after 240s

That approach is not in this PR. The bound has to be ours, at the one place that knows what waiting means.

The change

RvServiceWaitPaired takes a timeout. Expiring is not an error — it means "nobody came, go round again", which the loop already handles. Cost is one reconnect per relay per five minutes. The socket returns to blocking once a dial lands, because from then on it is a data tunnel and tunnels are allowed to sit quiet.

Verification

Path killed silently — dropping only the relay's replies, so no RST or FIN is ever seen. Test build bound at 60s:

15:59:12  path killed
     40s  rendezvous: no dial at 92.246.128.180:8434 within 60s
          (or it dropped us), re-registering
          registrations 1 → 2, node carried on

Under the same treatment before this change, the node was still blocked past four minutes with no log line at all.

• Linux: recovers on its own, logs the reason
• Windows: registers and syncs normally, no regression
• Production value is 300s; 60s was only to make the test converge

Not covered here

The relay's own side. bitflashd holds a registration socket per waiting client and has the mirror-image problem — a client whose path dies leaves a dead entry that the relay then hands out, which is one source of "ghost" addresses. The relay is built from a separate tree on the VPS and redeploying it is an infrastructure change, so it belongs in its own piece of work rather than being folded in here.

[Bitflash-sh]

Branch name is a leftover: it says fix/rendezvous-keepalive because keepalive was where I started. The measurement above is why it is not what shipped. Renaming the branch would break the PR, so it stays — the code has no keepalive in it.