Resume a test already running on the dock, as last-resort recovery from a severed connection

#8 recovers a test whose link glitched: the controller survives, the reconnect lands,
and the curve comes out continuous. One case it cannot reach is when the **host's**
Bluetooth adapter is cycled — that renderer's Web Bluetooth scanning never works
again. Measured: zero device events across three minutes and many retries in the
affected renderer, while a freshly launched process found the dock in 0.4 s. No
amount of clicking Reconnect helps, because the scan itself is dead.

Salvage still fires, so the data up to the break is on disk. But the run is
abandoned: the app sits in "Connection lost", the dock keeps testing for another half
hour, and the result is never captured.

## What makes this fixable

The dock accepts connections mid-test and reports `BLOCKED_ALREADY_TESTING`
(test state 4), offering **Continue tracking current test** — confirmed on hardware
(see #8). And a fresh renderer can always find it. So the recovery is available; it
just needs a new page, which only the native side can arrange.

## Sketch

1. **Trigger.** After recovery has failed for a sustained period (~90 s of unsuccessful
reconnects), and *only* once a salvage has succeeded, have main call
`win.webContents.reload()`. Ordering matters: the data must already be on disk,
because the reload destroys the controller.
2. **Reconnect.** Existing automation handles this — it is exactly a cold start.
3. **Resume.** On landing in test state 4, click "Continue tracking current test".

Step 3 needs care, and interacts with #10. That screen asks which kit the test was
*originally started with*, because the answer decides how results are interpreted;
#10 says we must stop pre-selecting a kit there, since a remembered kit can disagree
with a running test (notably when the test was started from the dock's own button,
which always defaults to SARS-CoV-2).

But a resume that *we* initiate is different: this app watched the test start and
knows what it was started with. Persisting `{kit, startedAt, serial}` to `config.json`
when we observe a transition into TESTING would let an auto-resume re-apply the right
kit with justified confidence, while a cold start with no such record still leaves the
choice to the user. Worth doing as part of this.

## Open question

Whether the dock **backfills** the samples missed during the outage, or only streams
forward from the resume point. `resumeTest()` clears `testData` outright, so the
resumed session starts a fresh series either way, and the run ends up as two files:
the `-partial-` capture from the break plus a final one from the resumed session.
Whether the final one covers the whole run or only its tail depends on the dock.

There is a hint that it backfills: each sample carries `sampleStreamNumber`,
`currentDataIndex` and `totalNumberOfSamples`, which reads like an indexed bulk
transfer ("sample 12 of 70") rather than a live-only feed. Untested — and cheap to
test, since an empty dock gives a free 5m44s run (see #8) and the answer only requires
clicking Continue and looking at whether the curve redraws from zero.

If it does not backfill, consider stitching the two exports at save time rather than
leaving the user to reconcile them.

## Smaller version worth having regardless

A **File → Reload and Resume** menu item doing the same thing manually. Useful on its
own, and it makes the automatic path testable without waiting out a 90 s timer.

Start with the existing recovery flow from #8, the native-side reload entry point using win.webContents.reload(), and resumeTest(). Review how salvage data and config.json are persisted, then trace the cold-start automation and test-state-4 screen. Done means a manual reload-and-resume path works, automatic recovery waits for salvage and failed reconnects, and the observed kit, start time, and serial are restored without losing the partial capture.

Written by the indexing model from the issue text.