[codex] Start the guardian child session when parent session is started

[jgershen-oai]

Why

The first auto-review currently creates its Guardian child session on demand, adding avoidable latency before the review can begin. Creating the ordinary Guardian child during parent-session initialization lets that child use the existing session startup WebSocket prewarm before the first escalation. This does not introduce a Guardian-specific prewarm mechanism.

What changed

• initialize the existing Guardian review-session manager owned by Session when a thread starts with auto-review enabled and an approval policy that routes to Guardian
• use the standard Guardian child-session construction and the existing session startup WebSocket prewarm
• preserve the existing reuse-key invalidation and lazy creation fallback when startup initialization fails or the effective review configuration changes
• add an integration test that verifies normal root-session startup emits a Guardian generate=false prewarm request

Benchmark

I compared release builds against main. Each prompt first ran a non-escalated sleep 3, then requested an escalated marker command.

binary	count	avg Guardian duration	median Guardian duration	avg Guardian TTFT
origin-main	10	4008.7 ms	3949.5 ms	3746.5 ms
session-fix	10	2865.0 ms	2594.0 ms	2492.7 ms

Guardian duration fell by 28.5% and Guardian TTFT fell by 33.5%. These measurements cover Guardian review latency; they do not measure parent thread-start latency.

[dylan-hurd-oai]

Non-blocking but we might also want to trigger this when a user switches permissions mid-thread