fix: capture the pipe before the supervisor deletes its own record

[zcsizmadia]

#446 did not fix #429, and the nightly said so. Same failure, byte for byte.

#446 had spawnSupervisor read the recorded endpoint to decide whether to forward --pipe. But runSupervise clears that record on a clean exit:

defer func() { supervise.ClearEndpoint(opts.StateDir) }()

and restart --supervisor exits the old supervisor cleanly before spawning the replacement:

1. old supervisor exits → endpoint record deleted
2. spawnSupervisor → ReadEndpoint → nothing
3. replacement re-selects from scratch

I read the record after the thing that writes it had removed it. It worked for a hard kill, where the record survives — which is why the test passed. That test wrote an endpoint and called supervisorCommand directly: it modelled the crash path, not the restart sequence. The right assertion about the wrong scenario.

The fix

runRestart captures the pipe before recycling and carries it through runStartPreserving to spawnSupervisor. The recorded read stays as the fallback, because for a supervisor that died hard it is the only thing that remembers which pipe was served.

runStartPreserving rather than a --pipe flag on start: this is not something a user asks for, it is one command carrying a value across a teardown that would otherwise erase it. A CLI flag would document a decision the caller never makes.

Verification

TestRestartSequencePreservesTheCustomPipe walks the real ordering — record written, captured, cleared, then the replacement built — and fails against exactly the code #446 shipped:

args [supervise --state-dir ...] carry pipe "", want "\\.\pipe\skrog-e2e-suite"

TestCrashRestartUsesTheRecordedPipe covers the other direction so the fallback cannot rot.

I am not claiming this closes #429 until the acceptance suite says so. Making that claim without running it is what was wrong last time.