Real-app Retry proof

Both sides: Linux web client, Chromium preview browser, 1280 x 800 CSS pixels,
2x capture scale, light theme; independent fresh server homes; synthetic project
"Update retry demo"; providers disabled through Settings. No agent turns needed.

The app and actual service launcher came from each requested commit. The web
client ran through Vite with APP_VERSION=0.1.9 and single-origin proxying. The
fixture changed only server package version metadata to 0.1.8 initially, then
restored 0.1.9. Shell entry wrappers execute the actual source CLI under Node;
no update RPC, service rejection, retry logic, or client config was mocked.
The installed target's preflight entry was deliberately made to exit 1 for the
initial update failure, then repaired for the manual upgrade.

Steps on both sides:
1. Pair web client with the real background-service launcher running 0.1.8.
2. Start sidebar Update 1 server, confirm Update to 0.1.9.
3. Observe failed run: "Could not prepare t3@0.1.9 while running the staged service preflight."
4. Stop only the isolated service; repair its target entry; select 0.1.9 and restart.
5. Keep the browser window open; let it reconnect (use Retry now if needed).
6. Read the actual client's config atom: connected, serverVersion 0.1.9.
7. Open failed capsule and press its Retry button; record the UI and observe outgoing WebSocket frames.

Observed base:
- Client connection: connected; config serverVersion: 0.1.9.
- Outbound Request tag: server.updateServerWithProgress.
- Request payload: {"targetVersion":"0.1.9"}.
- Real launcher rejection displayed: "Remote updates must select a newer server version."
- Capsule remains failed; Retry remains available.

Observed head:
- Client connection: connected; config serverVersion: 0.1.9.
- A page-global marker set before service restart remained present after reconnect and Retry.
- Outbound updateServer requests after Retry: zero.
- Failed capsule disappears, Retry disappears, run closes.

Outbound observation only wrapped WebSocket.prototype.send to retain string
frames, then called the original send with identical arguments; it did not
intercept, rewrite, or synthesize responses. Config was read using the app's
existing registry and serverEnvironment.configValueAtom.

Each final still was taken twice at least 500 ms apart; ImageMagick comparison
reported zero different pixels on both sides. Recordings show the Retry
interaction, with their first six seconds retained at their original timing.
Private host labels are covered with gray rectangles. Diagnostics and controls
are intact. All captures were inspected before upload.

Scope limits: desktop shell/IPC, provider diagnostic retention, and a pending
desktop update were not exercised. This proves the shared web Retry flow with
one satisfied server target and no other pending work.

AI-assisted; verified with the tests and tools listed above.