WSL runtime cache: install-timeout, prune, and lock-file follow-ups #150

Follow-ups from the independent review of #141, none of which blocked merging but
all of which want a real Windows+WSL machine to verify.

Fatal node-pty failures reinstall on every launch. After a fatal probe
failure the staged runtime is invalidated, which guarantees an identical
reinstall next start. For a systematically unloadable prebuilt (old glibc, musl)
every launch pays a full cold install and then falls back to /mnt anyway. No
backoff, no negative cache.

A 2-minute timeout can silently disable the cache forever.
RUNTIME_INSTALL_TIMEOUT bounds the blocking flock wait plus the cold
extraction read across /mnt/c. Exceed it and the app runs from /mnt
indefinitely with no retry. The adjacent comment claims "120 minutes is far past
any live install", which does not match the constant.

Orphaned scratch trees are never swept. Prune's [ -d /proc/1 ] || exit 0
sits before the orphan-scratch sweep — exactly the case where the install script
preserved the old tree as .stale.*. One abandoned runtime per update, unbounded.

Pruned runtimes leak their .<id>.install.lock siblings. Nothing removes
them.

Verification note for whoever picks this up

The tests that would catch a real bug in the install script are gated behind
describe.skipIf(posixShellRunner === null), which requires flock,
sha256sum, tar, and mktemp. flock is absent on macOS, so that whole
block skips and the suite still reports green. Ten tests skip on a Mac. Only the
string-generation tests run there.

Recorded in .agents/upstream-review.md. Related: #141.