fix: re-arm the approver inbox with exponential backoff (R1.5)

[stormer78]

First of the audit findings. The R1.5 defect CLAUDE.md warns about was fixed on the worker inbound path — but the approver inbox, added later as a deliberately parallel pool, kept it verbatim.

The bug

offscreen.ts:1377-1384 (before):

onClose: () => {
  approverPool.delete(key);
  if (approverIdentities.has(vtaDid)) {
    setTimeout(() => void getApproverWarmSession(vtaDid).catch(() => undefined), 2000);
  }
},

One fixed 2s retry, scheduled only from onClose, failure swallowed by .catch(() => undefined). If that retry failed, no session ever opened — so onClose could not fire again and nothing re-armed. A mediator outage longer than ~2s left the approver's inbox permanently dead until the operator happened to re-run the biometric unlock.

That is the inbox which receives task-consent/request. A dead listener there means gated actions silently never get their human check — the security control simply doesn't happen, and nothing reports that it didn't (R1.5, R7.2).

The fix

Adds ReconnectScheduler to core:

• retry forever — cap the delay, never the attempt count
• re-arm on every failure, including first-connect (no open ⇒ no close, which is the hole the old design had)
• never stack timers per key; reset to base on success
• optional shouldRetry gate so an operator lock beats a retry already in flight
• injectable timers, so the loop is testable without real waiting

The worker path deliberately keeps its own copy. That pool is documented as isolated so it "can never disturb the working worker inbound path" — adopting the shared scheduler there is a change to that path, not this one, and belongs in its own PR.

Verification

9 new tests: re-arm after failure, doubling + cap, 60s-outage recovery, reset-on-success, timer non-stacking, lock-beats-retry-in-flight, cancel-during-flight, per-key independence.

Critically, I mutation-tested them — reintroduced the original defect (removed the re-arm) and confirmed 4 of 9 fail, including "a mediator down for 60s recovers on its own". They detect the bug rather than merely passing alongside it.

Full suite 180/180 (was 171), clean build and lint, MV3 single-bundle guard holds.

Not verified: not exercised against a live mediator in a loaded extension. The logic is unit-tested against a fake clock; the wiring into createApproverWarmSession.onClose is not. A real approver flow with the mediator stopped and restarted would confirm end-to-end.

Follow-ups from the same audit (not in this PR)

1. register-gateway.ts:71-75 throws on status before reading the body, on a consent-capable endpoint — R3.7, same bug rest-channel.ts was fixed for
2. rest-channel.ts:91 consumes the body, so errorFromResponse re-reads a used stream and always loses the server's code — R3.7 violated inside the R3.7 fix (proven with a repro)
3. Nine fetch call sites lack timeouts, hidden from grep by injected-fetch indirection; getVtaBearer is worst since it runs before every REST request — R1.2
4. Persist-before-ack is violated structurally in vti-didcomm-js — needs cross-repo coordination (R4.1/R1.6)

Pre-merge checklist

• No new bare fetch(); timeouts (R1.2) — no network code added
• No lock held across a network await (R1.3) — n/a
• No local state committed before its remote effect (R2.1) — n/a
• Every retry bounded + backed off; non-idempotent ops not blind-retried (R1.4) — delay is bounded at 60s; the retried op is idempotent session establishment
• Accept/poll/listen loops survive transient errors (R1.5) — this is the fix
• Acks/deletes only after durable handoff (R1.6) — untouched; see follow-up 4
• New/changed wire types (R3.*) — none
• Config absence = most restrictive (R5.*) — shouldRetry defaults to not resurrecting a locked identity
• Logs/status claim only what was verified (R6.*) — failed connects now log a warning instead of being swallowed
• "Process dies on the next line" answered (R2.1) — scheduler state is in-memory; an offscreen teardown drops pending retries, and reconcileInbound/unlock re-establishes on restart, same as before
• Deviations flagged with rule numbers — worker path intentionally not unified; rationale in code comment