Feature: Expose per-prompt user input timing in statusLine data

Feature: Expose per-prompt user input timing in statusLine data

Summary

The custom statusLine command currently receives cost.total_duration_ms (wall clock / lead time) and cost.total_api_duration_ms (API thinking / cycle time). The gap between these two values lumps together:

• Time the user spends idle (reading output, thinking, away from keyboard)
• Time the user spends composing a prompt (first keystroke to submit)
• Tool execution time, permission prompt wait time, etc.

There is no way to distinguish these with the current data.

Proposed fields

Add the following to the statusLine JSON under cost (or a new user_input section):

| Field | Description |
|---|---|
| total_user_input_duration_ms | Cumulative time from first keystroke to submit, summed across all prompts |
| total_user_idle_duration_ms | Cumulative time where no input activity occurred (between API response completion and next first keystroke) |
| total_tool_execution_duration_ms | Cumulative time spent executing tools (outside API calls) |

At minimum, total_user_input_duration_ms would be the most valuable addition -- it lets users measure their own "prompting time" vs "idle/reading time" and display it in custom status lines.

Use case

I maintain a custom statusLine that shows lead time, cycle time, and focus percentage. I'd like to break down the non-API time into:

• Prompting time -- how long I actively spent writing prompts
• Paused time -- true idle time where I wasn't typing at all

This helps measure personal productivity and understand where session time actually goes.

Current statusLine data shape (for reference)

{
  "cost": {
    "total_cost_usd": 0.12,
    "total_duration_ms": 300000,
    "total_api_duration_ms": 120000,
    "total_lines_added": 50,
    "total_lines_removed": 10
  }
}

Desired addition

{
  "cost": {
    "total_user_input_duration_ms": 45000,
    "total_user_idle_duration_ms": 135000,
    "total_tool_execution_duration_ms": 0
  }
}

The data is already implicitly available inside the input handler (keystroke events with timestamps exist) -- it just needs to be accumulated and exposed.