fix: resolve temporary new-thread IDs before deletion

[Rat0323]

Summary

• resolve newly-created sidebar rows whose DOM ID is still local:client-new-thread:* to the persisted conversation UUID before deletion
• refuse to send a temporary client ID to local storage and show a synchronization retry message when the canonical UUID is not available yet
• re-read the row reference when the delete button is activated and observe thread ID/href attribute promotion so stale IDs are not retained
• add a renderer injection regression contract for the temporary-ID guard

Root cause

Codex initially renders a new sidebar conversation with a client-only placeholder ID such as local:client-new-thread:*. The persisted thread already exists under its UUID, but Codex++ preferred the placeholder DOM attribute and sent it to the delete endpoint. Local storage correctly returned Thread not found in local storage. Restarting rebuilt the sidebar with the canonical UUID, which is why deletion then succeeded.

Validation

• cargo fmt --all -- --check
• cargo test -p codex-plus-core --test cdp_bridge (95 passed)
• npm test --prefix apps/codex-plus-manager (36 passed)
• git diff --check

Integration note

This is intentionally independent from #1737. If #1737 lands first, this PR may need a small rebase around the delete event delegation block. The known cross-platform line-ending CI fix remains tracked separately in #1735.