fix(browse): server runtime — restore off the boot path, shutdown that cannot hang, watchdog that still reaps tunnels

Four review findings on the wave's own new wiring: session restore ran
before Bun.serve with sequential 15s gotos while the CLI gives up at 8s
(one slow saved URL bricked every $B command) — restore now runs in the
background after bind; the shutdown snapshot gets a 2s deadline so a
wedged page.evaluate can't hold the port forever behind the new
ack-first stop; the persistence ticker gets in-flight + shutdown gates
and is cleared before the final snapshot; and the absorbed #2565
handoff fix no longer clears the whole parent watchdog — a suppress
flag keeps the tunnel-orphan reaper alive (handoff→resume→tunnel is no
longer an unreapable internet-exposed daemon). pair-agent with consent
off now names the real remedy instead of ngrok install instructions.
Lock-acquisition edge branches (garbage pidfile, vanish-race depth cap)
pinned.

browse/test/server-lock-errors.test.ts

@@ -15,6 +15,10 @@
 
 import { describe, test, expect, afterAll } from 'bun:test';
 import * as fs from 'fs';
+// Default (CJS) export — its properties are mutable in Bun, unlike the frozen
+// `* as fs` namespace, and mutations propagate to cli.ts's own fs import.
+// Used only for the depth-cap livelock simulations below (restored in finally).
+import fsMutable from 'fs';
 import * as os from 'os';
 import * as path from 'path';
 import { acquireServerLock, ServerLockError } from '../src/cli';
@@ -77,4 +81,43 @@ describe('acquireServerLock (#1084 error honesty)', () => {
     expect(acquireServerLock(lockPath)).toBeNull();
     fs.unlinkSync(lockPath);
   });
+
+  test('EEXIST + garbage lockfile content: NaN pid is treated as stale, lock acquired', () => {
+    const lockPath = path.join(tmpRoot, 'garbage.lock');
+    fs.writeFileSync(lockPath, 'not-a-pid\n'); // parseInt → NaN → falsy → stale path
+    const release = acquireServerLock(lockPath);
+    expect(release).not.toBeNull();
+    // Our pid replaced the garbage — the stale lock was removed and re-acquired.
+    expect(fs.readFileSync(lockPath, 'utf8').trim()).toBe(String(process.pid));
+    release!();
+    expect(fs.existsSync(lockPath)).toBe(false);
+  });
+
+  // NOTE: the "stale lock that survives unlink" livelock variant is deliberately
+  // not simulated here — the source removes locks through safeUnlink's own fs
+  // binding, which a test-side fs monkey-patch cannot reliably intercept in Bun.
+  // The depth cap itself is exercised by the vanish-race test below.
+
+  test('depth cap: holder that vanishes between open and read returns null after 5 retries', () => {
+    // The EEXIST → readFileSync ENOENT race: the lock exists at openSync but
+    // is gone by the read (holder released in between). Repeated forever
+    // (open/release storm), the same depth cap must bound the retry loop.
+    const lockPath = path.join(tmpRoot, 'vanish.lock');
+    fs.writeFileSync(lockPath, `${process.pid}\n`);
+    const origRead = fsMutable.readFileSync;
+    try {
+      (fsMutable as any).readFileSync = (p: fs.PathLike | number, ...rest: unknown[]) => {
+        if (p === lockPath) {
+          const e: NodeJS.ErrnoException = new Error('mock: lock vanished before read');
+          e.code = 'ENOENT';
+          throw e;
+        }
+        return (origRead as any)(p, ...rest);
+      };
+      expect(acquireServerLock(lockPath)).toBeNull();
+    } finally {
+      (fsMutable as any).readFileSync = origRead;
+      fs.unlinkSync(lockPath);
+    }
+  });
 });