Resume after reconnecting can show stale working state without model invocation

What issue are you seeing?
When a Codex CLI session is in a reconnecting state (retrying after a stream disconnect), if I close that Codex instance and then resume the same thread, the resumed session can show a persistent working state even though no actual model sampling is happening.

It looks like a stale in-progress state: the UI indicates work is ongoing, but the turn does not progress.

What steps can reproduce the bug?

1. Start any task/conversation.
2. Trigger a reconnecting state (stream disconnect retry).
3. While it is reconnecting, close/shutdown that Codex instance.
4. Resume the same thread/session.
5. Observe: the resumed session may stay in "working" with no progress.

What is the expected behavior?
After resume, the session state should reflect the real engine state. If no sampling request is active, it should not display "working". It should either resume the in-flight request correctly, restart it, or surface an error/idle state that allows the user to retry.

Runtime environment

• OS: Arch Linux (rolling)
• Window manager/session: Hyprland (package version 0.53.3-2.1)
• Terminal: kitty 0.45.0
• Codex CLI: 0.101.0

Logs (sanitized)

• WARN ... stream disconnected - retrying sampling request (1/5 in 188ms)...
• WARN ... stream disconnected - retrying sampling request (2/5 in 405ms)...
• INFO ... Resumed rollout successfully from [redacted rollout file]
• INFO ... interrupt received: abort current task, if any
• ERROR ... state db missing rollout path for thread [redacted]

Possible cause (hypothesis)
This looks like a mismatch between persisted session/rollout state and the live runtime: the UI restores a "working/reconnecting" status but the underlying sampling stream is not reattached after resume, so nothing is actually running. If state reconciliation falls back incorrectly when rollout metadata cannot be found, the UI may never get updated back to idle/error.