Expose total_files_modified in the status line payload

## 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:

```js
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.

```js
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//events.jsonl` from the script — rejected as fragile (race conditions with the writer, 200 ms refresh budget, parsing a growing JSONL on every tick).

從 statusLine.command 的 payload 建構開始，追蹤現有成本欄位如何從 runtime 的 codeChanges.filesModified 狀態中組裝。將計數與其他成本欄位一起加入，然後確認 status line 接收到的 total_files_modified 是一個數字，且現有的 payload 欄位維持不變。

由索引模型根據 Issue 內容生成。