Flaky codex-core unified_exec test: race in reusing_completed_process_returns_unknown_process

Summary

I’m seeing an intermittent failure in codex-rs/core/src/unified_exec/mod.rs for test:

reusing_completed_process_returns_unknown_process

The failure appears timing-dependent rather than deterministic.

What fails

After sending exit to an interactive shell, the test currently expects the next write_stdin poll to return UnknownProcessId immediately.
Intermittently, the first poll can instead return a final completed-process response, and only the subsequent poll returns UnknownProcessId.

Failure signature

The observed failure path is consistent with:

expected unknown process error

when the first post-exit poll returns Ok(...) instead of Err(UnknownProcessId { ... }).

Why this looks flaky

This appears to be a race between:

1. Process completion and final output delivery.
2. Removal of the process from the manager store.
3. The first post-exit polling call in the test.

Reproduction

This is intermittent, so single runs may pass. Repeating the exact test increases repro chance:

for i in $(seq 1 200); do
  cargo test -p codex-core reusing_completed_process_returns_unknown_process -- --exact --nocapture || break
done

Expected behavior

Please clarify intended contract for the first post-exit poll:

1. Must it always be immediate UnknownProcessId?
2. Or is one final terminal response acceptable before UnknownProcessId?

If option 2 is acceptable, the current test assertion is too strict and can flake.