fix(scrypt): bound the reconnect catch-up so a flapping socket cannot chain full re-fetches

[Danswar]

Why

catchUpAfterReconnect re-armed itself for every reconnect observed while it was running:

do {
  this.catchUpPending = false;
  await Promise.allSettled([fetchAll(EXECUTION_REPORT), fetchAll(BALANCE_TRANSACTION)]);
} while (this.catchUpPending);

A round is a full re-fetch of both bulk streams — its cost scales with the account history, not
with the length of the outage it repairs. Once a round takes longer than the interval between drops,
every round ends with catchUpPending already set again, so the loop re-arms faster than it
completes and the venue is re-fetched continuously. There is no backoff and no cap, so it cannot
converge on its own.

That is what production has been doing since 2026-07-27 09:26 UTC. The first drop was ordinary — the
socket had been closing 1–3 times per hour for days. The catch-up that followed it timed out on both
legs (30 s each), the socket died two seconds later, and it has not escaped the loop since:

	before	since
WS code: 1006 closures	1–2/h	60–105/h
catch-up ERROR lines	~0	~100/h (751/24h)
WS handshake 401 (venue throttling)	0	6–46/h

Median connection lifetime is now 28 s. The one connection that survived 28 minutes in the last six
hours is the one where no catch-up round ran on it.

This is not only log noise: a connection in this state is what produces unobserved order outcomes
(see #4405, where two withdrawals were recorded Failed while they had executed at the venue).

What changes

• At most one round per catchUpMinInterval (5 min), however many reconnects arrive. The stamp
  is taken at the end of a round, so the gate is a cooldown: a round that outlasts the interval
  cannot let the next one start immediately. An isolated reconnect long after the last round waits
  not at all.
• At most catchUpMaxRounds (3) rounds per invocation, and anything still owed when they run out
  — a failing leg, or a reconnect that arrived too late to be serviced — is handed to a scheduled
  re-entry one interval later rather than dropped. onReconnect only fires on the next drop, so
  without this a socket that stabilises right there would leave the gap unrepaired until restart. A
  live invocation supersedes a scheduled retry; the retry restarts from the full pair.
• A round re-fetches only the legs that actually failed — unless a reconnect coalesced into the
  invocation. That reconnect's outage postdates the round's snapshots, so it invalidates both
  streams and the next round owes both again, not just the previously-failed leg.
• The constructor warm-up claims the first slot only if both legs loaded, so a reconnect right
  after boot doesn't repeat a pair of fetches that just succeeded — but does repair immediately when
  the warm-up left the caches incomplete.
• The legs run sequentially instead of concurrently, so only one bulk fetch is on the socket at a
  time. Leg isolation is unchanged: a failing execution-report fetch still doesn't cost us the
  balance transactions.
• Failures stay ERROR. A failed catch-up is a real state gap — the missed events stay missed
  until a later round restores them — so it is not downgraded. Its volume is bounded by the round
  gate rather than by suppressing lines, and a recovered streak is logged.
• The catch-up streams are dispatched through a keyed map rather than a switch, so adding one
  without a fetcher is a build error instead of a leg that reports itself caught up without fetching.

Deliberately not in this PR: what pushed the drop rate up at 09:26 in the first place is still
open. This removes the amplifier that turned an ordinary drop rate into a self-sustaining loop, and
the drop rate after it ships is the cheap read on whether anything else is wrong.

Verification

• scrypt.service.spec.ts: 29 tests. The ones that pin this change: rounds stop at
  catchUpMaxRounds on both the failure path and the success-plus-re-arm path (the latter is the
  shape the old loop never escaped); a reconnect arriving during the slot wait after a partially
  failing round re-fetches the healthy leg too; the scheduled retry fires and re-enters; the slot is
  stamped at the end of a round; the gate does not delay an isolated reconnect; and the warm-up
  claims its slot only when both legs loaded. The two narrowing tests are pinned from both sides —
  always widening breaks leg isolation, never widening breaks three cases.
• Full suite at HEAD: 5321 passed, 302 suites, 0 failures.
• tsc --noEmit, eslint, prettier --check clean.

Post-deploy verification owed

Scrypt reconnect catch-up … failed drops to at most one line per leg per 5 min while the connection
is unhealthy; WS 1006 closures and handshake 401s are the number to watch — if they fall back
toward the 1–3/h baseline once we stop re-fetching, the loop was driving them.

[Danswar]

Took 5 review passes (two independent lanes each — conformity and logic) to reach zero findings. What the passes changed, since several of them were real defects in the fix itself rather than in the original code:

1. The min-interval gate was stamped at round start, so a round outlasting the interval left wait <= 0 and rounds still chained back to back — a no-op in exactly the regime this PR targets. Now stamped at the end, making it a cooldown.
2. Exhausting the round budget dropped a still-set pending reconnect or a still-failing leg silently. onReconnect only fires on the next drop, so a socket that stabilised right there left the gap unrepaired until restart. Leftover work is now handed to a scheduled re-entry.
3. The constructor claimed the first catch-up slot unconditionally, including when both warm-up fetches had rejected. It now claims it only when both legs actually loaded.
4. The "retry only the failed legs" optimisation then opened a new gap: outstanding carries failed legs, catchUpPending carries a reconnect whose outage postdates the round's snapshots. Consuming the flag while outstanding stayed narrowed meant a new drop was serviced by a round that never re-fetched the healthy leg — and if the failed leg then succeeded, nothing was owed and no retry armed. develop did not have this hole. The pending check now sits exactly where the flag is consumed, after the slot wait.
5. An error de-duplication whose interval equalled the round interval could never trigger, and the test asserting otherwise only passed because a mocked delay froze the clock. Removed — the round gate already bounds the output.
6. The stream switch became a keyed map, so an unmapped stream is a build error instead of a leg reporting itself caught up without fetching; the detached retry got a rejection handler; plus comment/title accuracy.

Verification: 29 spec tests, and the ones pinning this change were mutation-checked from both sides — deleting the end stamp, reverting the pending-check placement, making the retry inert, and always- or never-widening the owed list each fail a specific named test, while re-adding the deleted pre-round stamp changes nothing. Full suite 5321 passed / 302 suites / 0 failures; tsc, eslint, prettier clean.

Note for the reviewer: this deliberately does not touch what raised the drop rate in the first place. It removes the amplifier that turned an ordinary drop rate into a self-sustaining loop; the WS 1006 and handshake 401 rates after deploy are the read on whether anything else is wrong.