fix(codex): handle current desktop CDP layout

[yoruuuchan]

Summary

• deprioritize Codex's auxiliary avatar-overlay CDP target so the main renderer is selected
• make codex ask track the latest assistant message identity instead of relying on virtualized turn/message counts
• add regressions for both behaviors

Reproduction

On Windows with OpenCLI 1.8.6 and current Codex Desktop, CDP 9238 exposes both:

• app://-/index.html?initialRoute=%2Favatar-overlay
• app://-/index.html

Because both targets otherwise receive the same effective score, /json order can select the overlay. codex status then reports Connected, while codex ask cannot find the composer.

After selecting the main renderer, prompts can be sent. Current Codex also virtualizes the thread DOM, so the number of [data-content-search-turn-key] elements may stay unchanged while a new assistant response replaces the visible turn. Assistant messages expose stable per-message identity through data-content-search-unit-key / data-response-annotation-target, which this change uses for polling, with the old turn-count behavior kept as a fallback for older builds.

Validation

• real Windows Codex Desktop E2E through CDP: askCommand.func(..., timeout: 60) returned DIRECT60_OK
• JS syntax checks passed for the modified Codex command and regression test
• regression tests added for CDP target selection and response detection

Local Vitest startup was blocked by a Windows Rolldown/native-binding lock in the temporary dependency install, so repository CI is the source of truth for the full test matrix.