[codex] fix Windows OAuth deep-link forwarding

[Jessomadic]

Summary

• Add a Windows-only pre-CEF named-pipe bridge for openhuman:// callbacks.
• Forward OAuth deep-link argv from the secondary process to the primary before the existing CEF mutex guard exits.
• Drain queued URLs after Tauri deep-link registration so the existing frontend listener handles login normally.

Root Cause

The Windows pre-CEF mutex guard exits secondary OpenHuman.exe launches before Tauri's single-instance/deep-link plugins can run. Browser OAuth callbacks arrive as a secondary launch with openhuman://auth?token=..., so the callback URL was dropped while the already-running app only regained focus.

Validation

• cargo fmt --manifest-path app/src-tauri/Cargo.toml --all -- --check
• git diff --check
• cargo metadata --manifest-path app/src-tauri/Cargo.toml --format-version 1 --no-deps

Blocked locally:

• cargo test --manifest-path app/src-tauri/Cargo.toml deep_link_ipc_windows --lib reached native build scripts but could not complete because this machine is missing libclang.dll for whisper-rs-sys and ninja for cef-dll-sys.

Related

• Refs OAuth deep link "openhuman://auth?token=..." is ignored on Windows 11 — app stays on login screen tinyhumansai/openhuman#2466
• Related to prior Windows hot-instance deep-link fix Windows desktop OAuth callbacks do not reach the running app instance tinyhumansai/openhuman#2228 / fix(tauri): forward hot-instance OAuth deep links tinyhumansai/openhuman#2229