feat(agent,websocket,status,channels): WebSocket tooling, session lifecycle, reasoning, chat_id

[JackLuguibin]

Enhance tool event handling and configuration
Session turn lifecycle notifications
Reasoning content handling for WebSocket channels; streamlined attachment across channels
Status and context commands JSON support
chat_id for WebSocket session resumption
OutboundMessage data field for additional payloads; docs and tests updated

[JackLuguibin]

@Re-bin

[Re-bin]

I like the direction of the WebSocket work here, but I don’t think this is ready to merge as-is.

The good part is clear:

• resumable chat_id sessions
• explicit chat_start / chat_end
• structured tool_event payloads
• a more frontend-friendly WebSocket protocol

That all makes sense.

Where this PR loses its boundary is that it also generalizes structured JSON command output and reasoning delivery across channels, but without a complete delivery contract outside WebSocket.

Two concrete problems stand out:

1. /status_json and /context_json now put their payload into OutboundMessage.data while leaving content empty. WebSocket handles data, but CLI and most other channels still render from content, so these commands effectively become empty responses outside WebSocket.

2. reasoning_content is now attached as a streamed follow-up for all channels when send_reasoning_content is enabled, but only WebSocket actually understands the _reasoning_only path. That means behavior is inconsistent across channels: some drop it, some send blank messages, and only WebSocket renders it correctly.

So the WebSocket-specific changes are promising, but the PR overreaches when it turns those transport-specific ideas into cross-channel behavior without fully implementing the other side.

I pulled the branch locally, reviewed the origin/nightly...HEAD diff, and reran:

• focused websocket / command tests
• the full test suite

Everything passes locally, but the functional boundary still isn’t clean enough.

My recommendation:

• either scope this PR down to WebSocket-only behavior
• or fully implement and document the cross-channel contract for data and reasoning delivery before merging

From my side, this is not merge-ready yet.

[Re-bin]

Closed due to #3216.