Improve Windows process management edge cases

[iceweasel-oai]

Summary

Some improvements to Windows process-management issues from #15578

• bound the elevated runner pipe-connect handshake instead of waiting forever on blocking pipe connects
• terminate the spawned runner if that handshake fails, so timeout/error paths do not leave a stray codex-command-runner.exe
• loop on partial WriteFile results when forwarding stdin in the elevated runner, so input is not silently truncated
• fix the concrete HANDLE/SID cleanup paths in the runner setup code
• keep draining driver-backed stdout/stderr after exit until the backend closes, instead of dropping the tail after a fixed 200ms grace period
• reuse LocalSid for SID ownership and add more explanatory comments around the ownership/concurrency-sensitive code paths

Why

The original PR fixed a lot of Windows session plumbing, but there were still a few sharp process-lifecycle edges:

• some elevated runner handshakes could block forever
• the new timeout path could still orphan the spawned runner process
• stdin forwarding still assumed a single WriteFile consumed the whole buffer
• a few raw HANDLE/SID error paths still leaked
• driver-backed output could still lose the last chunk of stdout/stderr on slower backends

Validation

• cargo fmt -p codex-windows-sandbox -p codex-utils-pty
• cargo test -p codex-utils-pty
• cargo test -p codex-windows-sandbox finish_driver_spawn
• cargo test -p codex-windows-sandbox runner_

Ran a local test matrix of unified-exec and shell_tool tests, all passing

[iceweasel-oai]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep it up!

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[jif-oai]

The startup ownership boundary still feels split: spawn_runner_transport owns the runner process only through pipe connect, but send_spawn_request / read_spawn_ready are still part of startup and can fail or time out after the process handle is closed