fix(ocap-kernel): re-dial relays on connection close with exponential backoff

[sirtimid]

Closes #859

Summary

• Add relay health monitor in ConnectionFactory that detects when relay connections close and automatically re-dials them with exponential backoff (5s → 10s → 20s → 40s → 60s cap, 10 max attempts)
• On successful re-dial, libp2p's reservation-store handles re-reservation internally — we only need to re-establish the connection
• Clean up pending reconnect timers on stop() to prevent leaked timers

Test plan

• Unit tests: relay reconnection triggered on connection:close for a relay peer
• Unit tests: non-relay peer close does not trigger reconnection
• Unit tests: backoff timing increases on consecutive failures (5s, 10s, 20s, 40s, 60s cap)
• Unit tests: max retry limit (10) respected
• Unit tests: stop() clears pending reconnect timers
• Manual: two kernels connected via relay → kill relay → restart relay → kernels auto-reconnect

🤖 Generated with Claude Code

---

Note

Medium Risk
Adds automatic relay reconnection with timers/backoff and new shutdown coordination, which can affect connection stability and resource cleanup if edge cases are missed. Changes are localized to libp2p connection management and covered by targeted unit tests.

Overview
Adds automatic relay reconnection in ConnectionFactory: when a connection:close event involves a known relay peer, the factory schedules a re-dial using calculateReconnectionBackoff with exponential delays (5s base, 60s cap) and a max of 10 attempts, while preventing duplicate reconnect loops per relay.

Improves lifecycle cleanup by tracking pending reconnect timers, clearing them on stop(), and guarding against reconnects during/after shutdown or when the abort signal is already aborted. Expands unit tests to cover reconnect scheduling, backoff progression, max-attempt exhaustion, stop-time cleanup, and several race/edge cases (e.g., stop during in-flight dial).

^{Written by Cursor Bugbot for commit d4eefb8. This will update automatically on new commits. Configure here.}

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	76.11% ⬆️ +0.06%	6639 / 8722
🔵	Statements	76% ⬆️ +0.06%	6745 / 8874
🔵	Functions	73.95% ⬆️ +0.07%	1653 / 2235
🔵	Branches	75.38% ⬆️ +0.07%	2472 / 3279

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/ocap-kernel/src/remotes/platform/connection-factory.ts	92.74% ⬇️ -2.81%	86.17% ⬆️ +0.06%	97.36% ⬆️ +0.49%	92.63% ⬇️ -2.82%	70, 79, 86, 166-171, 385, 530, 578-579, 584-588, 647, 660

Generated in workflow #3848 for commit d4eefb8 by the Vitest Coverage Report Action

[rekmarks]

Good to go, but a couple of things to consider.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}