Expose total_files_modified in the status line payload

[sinedied]

Feature request: expose total_files_modified in the status line payload

Context

The configurable status line (statusLine.command) receives a JSON payload on stdin with a cost object that currently includes:

cost: {
  total_api_duration_ms,
  total_lines_added,
  total_lines_removed,
  total_duration_ms,
  total_premium_requests
}

total_lines_added / total_lines_removed are great for showing a +12/-3‑style diff summary, but there's no companion field for the number of files touched in the session.

Proposal

Add total_files_modified: number (the count, not the array) to the cost payload sent to the status line script. The runtime already tracks codeChanges.filesModified internally (it surfaces in /usage and in session.shutdown events), so this is essentially exposing existing state.

cost: {
  total_api_duration_ms,
  total_lines_added,
  total_lines_removed,
  total_files_modified, // ← new
  total_duration_ms,
  total_premium_requests
}

Use case

Status line scripts can render a more complete change summary, e.g.:

Context 25k/100k [bar] 25% · ↑112k ⊚80k ↓5k ($0.35) · +42/-13 in 4 files

This is the natural complement to the line‑count fields and matches how most diff tools summarize changes (lines + file count).

Why a count and not the list

Sending the full path list would bloat the payload on long sessions and leak filesystem context unnecessarily. A simple integer count is enough for the status‑line use case.

Alternative considered

Reading ~/.copilot/session-state/<id>/events.jsonl from the script — rejected as fragile (race conditions with the writer, 200 ms refresh budget, parsing a growing JSONL on every tick).