feat(agent): emit a live tool-execution start item on the multi-turn stream

Child issue for #2118 Phase 1 (interactive run control / host observability): the stream needs a live tool-lifecycle signal that today only exists via hooks.

Summary

The multi-turn stream has no live tool-execution signal. ToolExecutionCommitted and ToolResult surface only after the whole tool batch settles (deliberately — batch commit is atomic), so a streaming consumer that wants to render "running tool X…" — a chat UI, an SSE bridge, any progress surface — has to register an on_tool_call hook and re-merge that side channel into its own stream, re-deriving correlation the stream already carries.

Hooks remain the right place for steering; pure observers should get a first-class stream item.

Proposal

A new MultiTurnStreamItem variant emitted at each tool call's actual start moment, one per dispatched call (not per batch), carrying the tool name and the existing internal_call_id so the full start ⟷ commit ⟷ result lifecycle correlates on ids consumers already track. The enum is #[non_exhaustive], so the addition is minor and non-breaking; every existing item keeps its position and the atomic-after-settle batch commit is unchanged.

Acceptance criteria

• One start item per dispatched call, emitted live (observable while the tool is still running), on both the sequential and tool_concurrency > 1 paths.
• Correlates with the model ToolCall item, ToolExecutionCommitted, and ToolResult via internal_call_id.
• Emitted for MCP-backed tools the same as local tools.
• Ordering contract documented on the variant; existing event ordering unchanged.
• Hook-skipped and never-dispatched (invalid-recovery) calls have defined, documented behavior.

I have an implementation ready and will open a PR against this issue.