Windows running thread resume rejects same rollout path with verbatim prefix

Problem

On Windows, rejoining a running Codex thread can fail with:

cannot resume running thread ... with stale path

The same rollout file can be represented with ordinary Windows syntax, for example C:\..., by the app client and with a verbatim prefix, for example \\?\C:\..., after backend canonicalization. The running-thread stale-path guard compares the raw path spelling, so it can reject the same active thread as stale.

Reproduction

1. Start a thread on Windows and keep it running.
2. Resume or rejoin it by rollout path using the alternate spelling of the same file, such as C:\... versus \\?\C:\....
3. The backend rejects the resume as stale even though both paths identify the same rollout file.

Expected

The backend should reject truly different rollout files, but equivalent spellings of the same file should rejoin the running thread.

Fix direction

Compare normalized filesystem identity for running-thread rollout path checks while preserving stale-path rejection for genuinely different rollout files.