Windows: running thread resume rejects same rollout path when one side uses \\?\ prefix

Summary

On Windows, creating or resuming work against an already-running thread can fail with a stale-path error even when the requested rollout file and the active rollout file are the same file.

Observed error:

cannot resume running thread 019e6296-8510-7243-8d00-c899d5139d9e with stale path: requested `C:\Users\Lenovo\.codex\sessions\2026\05\26\rollout-2026-05-26T12-41-37-019e6296-8510-7243-8d00-c899d5139d9e.jsonl`, active `\\?\C:\Users\Lenovo\.codex\sessions\2026\05\26\rollout-2026-05-26T12-41-37-019e6296-8510-7243-8d00-c899d5139d9e.jsonl`

The two paths refer to the same file. The only difference is Windows' verbatim / extended-length path prefix (\\?\).

Impact

This can leave Codex Desktop unable to create tasks or resume a running thread. It can happen repeatedly if persisted thread metadata and the active running-thread path use different Windows path representations.

Likely cause

thread_processor.rs compares params.path and the active running-thread rollout path with direct PathBuf equality before rejoining a running thread. On Windows, direct equality treats C:\... and \\?\C:\... as different even when they identify the same file.

Expected behavior

The stale-path check should compare normalized paths, so Windows verbatim and non-verbatim equivalents are accepted while genuinely stale or different rollout files are still rejected.