fix(core): include provider wait in token throughput timing - #47125

Summary

Fix inflated TUI output-token throughput for responses that arrive in a burst after waiting on the provider.

The denominator is the sum of time.streamed - time.created across the assistant's model steps. Previously, time.created came from the lazily published step-start event, which can arrive only after the provider has already spent most of the request generating the response. A deterministic 12-token fixture with 2,690 ms of provider wait and 10 ms of response delivery therefore reports 1,200 tok/s instead of about 4.4 tok/s across the request.

• Capture request start after snapshot preparation and before consuming the provider stream; carry it as an optional started timestamp on the existing step-start event.
• Use that timestamp in both durable and live client message projections. Preserve lazy event publication so overflow/full-context recovery does not create extra assistant messages.
• Reset the timestamp for a retried physical attempt so failed attempts and backoff do not enter the successful attempt's denominator.
• Keep the response-body end boundary, excluding local tool settlement time. This is request throughput including provider wait, not decode-only speed.
• Preserve older events without the new field. Missing historical request times cannot be reconstructed; this corrects newly recorded steps without inventing a backfill.

Validation

• Reproduced before the fix: buffered-response test expected a 2,700 ms interval and received 10 ms. It now passes, including durable replay.
• Core runner, publisher, message-update, and projector tests: 230 passed.
• Live client data tests: 25 passed, including new/retried messages, zero timestamps, and legacy fallback.
• TUI rows/data tests: 70 passed; rendered footer lifecycle test: 1 passed.
• Schema event/manifest tests: 12 passed, including optional-field encoding compatibility.
• Core, client, and schema typechecks passed; clients regenerated; formatting and diff checks passed.
• The broader schema contract-hygiene check still fails on existing Schema.Any usage. Confirmed the same failure with the schema source byte-identical to the base commit; not changed in this patch.

Requested by: @rekram1-node (Aiden via Slack)