The detached reap added in #665 could kill a live `codex app` session.

`codex app` relies on the detach grace rather than an explicit
`detachOnExit`, so its launcher exits inside the grace window and the
helper's owner is dead from the first tick. From then on the only thing
standing between the desktop app and a dead proxy was
`countOpenConnections() === 0` — and the proxy never sets
`server.keepAliveTimeout`, so Node closes idle client sockets after its
5s default. A user who stops typing for the length of the detached
window has zero sockets and no new requests, so the helper exits
`owner-gone`, and the next message gets ECONNREFUSED against a dead
localhost port with nothing left to restart it. Pre-#665 that session
survived for the full 12h idle timeout.

Gate the reap on the helper having *never* served a request. Every
leaked helper in the #663 report had `totalRequests: 0`, so the leak is
entirely a never-served phenomenon and the narrower gate closes it in
full; a helper that served anything was genuinely handed off and falls
back to the idle timeout and the 24h lifetime ceiling, which is where it
sat before the detached window existed.

Two more lifecycle fixes in the same tick:

- The owner verdict is now three-valued. "No owner PID was recorded" and
  "the owner is confirmed dead" are different facts, and collapsing them
  into one `false` started the detached clock on the first tick for any
  helper launched without an owner PID — invoked directly, which is the
  documented reproduction in #663, or spawned by a pre-upgrade launcher —
  and reaped it silently 15 minutes later. `unknown` fires neither
  branch, which is what the pre-#664 `ownerPid && isAlive(ownerPid)`
  guard did.

- The status heartbeat now accounts for the detached window.
  `publishToken` zeroes `idleExpiresAt`, so the published deadline only
  catches up on a heartbeat; pinned to the idle window alone, `rotation
  status` kept advertising a 12h deadline for a helper seconds from
  exiting, and under a short DETACHED_IDLE_MS override it never caught up
  at all.

Also in this commit, both from the same review pass:

- The metadata sweep runs after the helper spawn instead of before it.
  It is synchronous and unbounded — readdir, a readFileSync per live
  candidate, rmSync with a blocking backoff, bounded `ps` probes — and
  the state it cleans up is exactly the state that makes it slow, so it
  sat in front of `codex app` and TUI startup. Nothing about spawning
  depends on it. The launch timeout is armed after it either way.

- Sweep deletions are guarded by an mtime re-check. Classifying a file as
  stale and deleting it are two moments, and a PID freed between them can
  be handed to a helper starting right now, which republishes that exact
  path before the delete lands.

- The published wrapper's fault injectors need an explicit
  CODEX_MULTI_AUTH_TEST_FAULT_INJECTION=1 opt-in and a strict digits-only
  parse. `Number.parseInt` reads "2abc" as 2 and "1e3" as 1, so a value
  that was never meant to be a count could arm an injector in a user's
  install and silently defeat the first N metadata deletions of every
  sweep (#668).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015b4Lew3oHNEYmTZtg7zEWz