fix(runtime): agent-wake client-event translation, full-tail persistence, processing guard

[siddseethepalli]

Summary

Fixes 3 correctness gaps in wakeAgentForOpportunity identified during plan review.

1. Client event translation: wake no longer emits raw AgentEvents as ServerMessages. Events are translated via the canonical handler so clients receive correctly-shaped 'assistant_text_delta'/'message_complete' frames with conversationId.
2. Full tail persistence: wake now persists every message produced by the agent loop (assistant messages + tool_result user messages), not just the first assistant message. Prevents DB/history desync when the wake produces tool calls.
3. Processing guard: wake marks conversation.processing during the agent loop so concurrent user turns can't race and produce interleaved history.

Part of plan review for meet-phase-2-chat.md.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 83558efbf6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Drain queued messages when wake clears processing flag

wakeAgentForOpportunity now sets processing=true, so concurrent user sends are routed through enqueueMessage, but on completion it only flips the flag back to false and returns. If a user message arrives during the wake, it can remain stranded in conversation.queue until a later unrelated turn calls drainQueue, which can delay or reorder user messages (a fresh non-queued send can run before the older queued one). Please drain the queue as part of wake teardown (or avoid queueing in this path) before releasing processing.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Respect streamThinking setting in wake event translation

The new wake translator always emits assistant_thinking_delta for thinking_delta events, but the canonical conversation path only forwards thinking deltas when streamThinking is enabled. In deployments with thinking.streamThinking=false, wake-originated turns will still expose thinking output to clients, which diverges from configured behavior. This translation should be gated (or suppressed) the same way as the normal handler.

Useful? React with 👍 / 👎.

[siddseethepalli]

Follow-up shipped in #26265 — addresses consolidated review feedback (chat concurrency mutex, dispose teardown, wake adapter timeout/ghost prevention, tokenEstimationProvider forwarding, E2E test flakiness).