Split app-server EventMsg handling into mapping and side-effect handlers

What variant of Codex are you using?

CLI / app-server

What feature would you like to see?

Codex app-server event handling would be easier to maintain if EventMsg projection were split into clearer layers.

The current path appears to combine several responsibilities:

• mapping core events to protocol notifications
• mutating thread state
• handling approval and elicitation round-trips
• realtime and other side effects

Since app-server is an external integration boundary for clients, event projection bugs are user-visible. As the protocol grows, a single large event handler becomes harder to review and test safely.

A useful direction might be:

1. a pure adapter layer for EventMsg to protocol DTOs
2. small handlers grouped by event family
3. a dispatcher that only routes events to the right handler

This resembles an Adapter plus Handler Registry shape, but the main goal is separating pure protocol mapping from stateful side effects.

Additional information

Non-goals:

• No public API redesign.
• No immediate protocol shape changes.
• No broad rewrite.
• No behavior change except where covered by tests.