Navigating away from the app page silently disables keep-awake, stall detection and save-on-completion

The main window is a kiosk for one page, but nothing stops it navigating away from
that page — and when it does, every native behavior this wrapper exists for stops
silently.

## Observed

During the #8 hardware session (2026-08-23), a stray click while taking a screenshot
navigated the window to another page on virus.sucks. A test was running on the dock
at the time. The log goes from a working recovery loop straight to silence:

```
00:04:30.565 renderer [pluslife] reconnecting after drop
00:04:41.264 renderer [pluslife] automation installed <- new page, nothing left to drive
(nothing further)
```

`automation.js` reinstalls happily on the new page, and then does nothing forever:
every one of its behaviors looks up `pluslife-app` or ``, and neither
exists. So:

- **keep-awake is released** — the Mac is free to sleep mid-test, which is the exact
failure this app was built to prevent.
- **the stall watchdog stops** — no detection, no salvage.
- **save-on-completion never fires** — the results screen is never rendered, so the
test finishes into nothing.

None of it is announced. The window just shows a different page.

## Where the navigations come from

The upstream page has real links out of the app: the site logo (`href="/"`), plus
`/analyzer_webhooks` and `/impressum` in the footer. Any of them is one click away
from a running test, and there is no way back short of restarting the app.

## Fix

Handle `will-navigate` on the main window's `webContents`: allow the app URL (and
in-page navigation), send anything else to `shell.openExternal` instead, and add
`setWindowOpenHandler` for `target=_blank`. Worth adding a **View → Reload the
Analyzer** menu item too, as a way back if a navigation ever does slip through.

Care needed on two points:

- The upstream app is a PWA with a service worker; make sure the guard does not
interfere with its own registration/updates or with the `bluefy://` link it
offers on iOS (irrelevant on macOS, but the handler should not throw on it).
- `PLUSLIFE_URL` may point at a pinned local copy, so the allow-check has to be
against the configured URL's origin rather than a hardcoded virus.sucks.

Deferred for now; filed so it isn't lost.

Start at the main window's webContents navigation handling and inspect how PLUSLIFE_URL is configured. Add the navigation and new-window guards, the reload menu item, and verify that allowed in-page navigation, external links, service-worker behavior, and bluefy:// links remain safe and functional.

Written by the indexing model from the issue text.