fix(codex-bridge): give the identity lease a start token on Windows

[joelmitz]

Fixes #977.

The codex bridge could not start on Windows at all: startToken() had two
sources and Windows satisfies neither, so writeLease() failed closed on an
empty token every time and the launcher respawned it into the same wall.

/proc/<pid>/stat   ENOENT
ps -o lstart=      ps: unknown option -- o

The fail-closed is correct (#906) — the missing Windows source is what this adds:
Process.StartTime.Ticks through PowerShell, in both codex-bridge.js
startToken() and codex-bridge-launcher.sh _start_token, with pwsh admitted
to the lease schema.

One source, not a preference list

WMIC's CreationDate is ~2x cheaper (0.36 s vs 0.83 s measured) and was the
first implementation. It is dropped, and not because WMIC may be missing: a
per-side "WMIC, else PowerShell" order lets the writer and the reaper resolve
different sources for the same process whenever only one of them can reach
wmic.exe, and their tokens differ by format — so the reaper reads a live
bridge's lease as another process's. Reproduced with wmic shadowed on one side:

node: src=wmic token=20260824045224.102163+540
bash: src=pwsh token=639231439441021632

powershell.exe → pwsh fallback is safe where WMIC was not: both return
identical Ticks for a pid, so the src label names the format, not the binary.

The Windows branch replaces the /proc branch rather than preceding it

MSYS/Cygwin expose a working /proc, but it is keyed by their own pid space
while the lease records the Windows process.pid, so preferring it would return
an unrelated process's start time with nothing to signal it. Measurements in #977.

Tests

Six cases against _read_lease — the reaper's only gate on a lease, so its
accept/reject set is the contract that widening proc|ps to proc|ps|pwsh
changes. Exercised directly, the way tests/test_remote.bats already does for
_remote_endpoint_display, rather than through the reaper: that path needs a
spawnable bridge and a live pid, which is what does not work under Git Bash
(#567) and has nothing to do with the schema.

Two detect the change; four are guards. Stated as a table rather than a pass
count so a reviewer checking it finds the same thing:

case	with the change	without it
a pwsh lease parses	ok	fails
windows-native: a live pid yields an integer pwsh token	ok	fails
a pwsh token that is not an integer is rejected	ok	ok
an unrecognised startsrc is rejected (wmic included)	ok	ok
proc/ps still parse; proc non-numeric still rejected	ok	ok
POSIX: a live pid yields a proc or ps token	ok	ok

wmic is in the rejection case deliberately, not as an arbitrary bad value: it
pins the decision above, so reintroducing WMIC fails loudly.

Only the case that runs PowerShell carries windows-native in its name, so it
lands on that leg; the rest carry no marker and run everywhere. The two
platform-specific cases complement each other — on either leg one runs and the
other skips.

Verification

• Windows 11 26200 / MINGW64 / node 22 (win32) / codex-cli 0.149.0: the six cases
  pass; re-run against the parent commit's codex/ tree, the two
  change-detecting cases fail as tabled
• Linux (Bats 1.14.0 from a clone): the five non-windows-native cases pass and
  the mutation check reproduces. Run independently on a separate machine by a
  second person, not a re-run of the Windows box
• End to end on Windows: the bridge starts, publishes
  start=639231452158110466 startsrc=pwsh, and a message sent to the role drives
  a turn and gets an answer. Before this change the same sequence produced only
  the token error

Not verified

• bats tests/ green on Windows. That is not achievable and is not new: the
  workflow shards the suite over [ubuntu-latest, macos-latest] only, and the
  Windows leg runs filter: "windows-native". The full file has never been
  expected to pass under Git Bash
• launcher: windows-native starts the bridge (#567) fails on our Windows
  machine with and without this change. It asserts the half of codex bridge on Windows: port-detection liveness probe asks tasklist about an MSYS pid, so it always aborts on iteration 1 #567 that is not
  fixed: the parent-liveness probe asks tasklist about an MSYS pid, and the two
  pid spaces are disjoint (tasklist finds winpid 19568 only; kill -0 finds
  MSYS pid 3994449 only). The workflow already lists windows runtime (#567)
  among its known intermittent reds
• macOS is not covered by our own runs; the POSIX branches are untouched, but
  that is an argument, not a measurement

Unrelated flake, for context

tests/test_codex_bridge_launcher.bats flakes under full-suite load on Linux
independently of this change: baseline produced the same not ok 17 on one of
three full runs, and the failing test moves between runs, while single-test runs
were green 3/3 on both. We are not claiming equal rates — the run count is far
too small — only that the same failure occurs without this change.