feat(tui): show the output token rate (tok/s) in the status line

Feature request

Add a built-in tps slot to the status line showing the model's output token rate (e.g. 42.3 tok/s), and expose the same number to custom status line commands.

Why

While working I would like to see how fast the model is generating — at a glance, without leaving the session or digging for it. The status line is where persistent, at-a-glance session state already lives (mode, goal, model, tasks, cwd, git, tips), but there is no slot for throughput.

Proposal

1. A tps built-in slot, rendering the rate of the most recent measurable step and reorderable through [status_line].items like every other slot. Placing it after cwd in the default layout keeps it next to the other passive readouts.

Steps that finish too fast to time should leave the previous reading in place rather than clearing the slot — otherwise a run of quick tool calls makes the number blink in and out.

2. decodeTps in the command payload. A custom [status_line].command takes over line 1 outright, so with one configured the built-in slot disappears and the script cannot rebuild it — the value is not in the stdin snapshot. This is the same parity gap as #2394 (thinkingEffort), #2477 (terminal width) and #3573 (background task counts).

Additional information

One design point worth deciding explicitly: the natural source is output tokens over the stream duration, which is the rate observed at the client, not pure server decode speed. For a status line the observed rate seems the more honest choice — it reflects the speed actually perceived, including when the TUI itself is the bottleneck — but a server-side rate is an alternative.

A counter that ticks live during generation is deliberately not proposed: streaming deltas carry only text, so a mid-stream rate would mean estimating tokens from characters. Updating once per completed step keeps the number authoritative.

I have a working implementation against v0.41.0 and would be glad to contribute it if the team is interested.

Start by tracing the TUI status-line slot registry and the stdin snapshot used by custom status-line commands. Verify the completed-step timing and token data, with done defined as a reorderable tps slot, retained values for unmeasurable steps, and decodeTps in the command payload.