Expose large_output_file_path on TaskShellProgress so clients can read complete shell-task output

Describe the feature or problem you'd like to solve

TaskShellProgress.recentOutput is a small rolling window (~10 lines / ~80 chars). A client polling it to display a running shell task shows a lossy sample presented as the tail. Measured at 2s polling against a 10 lines/sec producer — consecutive polls are disjoint, so ~half the output is unobservable:

A complete log already exists. With largeOutput enabled the runtime writes a full, gap-free file — including for attached tasks (400 lines → bytes=3492 first=1 last=400 contiguous=true). The runtime knows the path: shell_attached_session_read returns recent_output, large_output_file_path, large_output_total_bytes.

The wire contract drops the last two, so clients cannot find the file.

Proposed solution

In schemas/api.schema.json, add to TaskShellProgress:

"largeOutputFilePath":  { "type": "string" },
"largeOutputTotalBytes": { "type": "integer" }

Optional, populated only when largeOutput is enabled and the threshold has been crossed — no change for existing consumers.

This must happen in the CLI: TaskShellProgress is defined here and the SDK's rpc.d.ts is generated from this schema (AUTO-GENERATED FILE - DO NOT EDIT / Generated from: api.schema.json). The definition also sets "additionalProperties": false, so the field is actively forbidden on the wire — no client-side or SDK-side change can surface it.

Example prompts or workflows

A GUI host showing live build output for a long-running shell task. Today it must poll recentOutput and stitch samples, knowingly dropping content.

Clients cannot work around this: largeOutput is session-scoped (fixed at createSession; no per-message option, no mid-session config update), so a directory-per-task mapping isn't possible. Concurrent tasks do get separate files, but creation order does not follow task order — tasks listed 1,0 produced files in reverse — so ctime correlation is unsafe. That leaves content-matching heuristics, which are genuinely ambiguous while two tasks emit identical output.

Additional context

• Still absent in 1.0.11: TaskShellProgress unchanged (3 fields), largeOutput appears 0 times in rpc.d.ts, while rpc.d.ts grew ~109KB with other features — looks unaddressed rather than deliberate.
• The file is written incrementally (one tracked its task from t=23s to t=44s), so exposing the path enables a real live tail.
• It appears only after the size threshold is crossed (~17s in one probe); brief absence is expected and easy to handle.
• TaskShellInfo.logPath doesn't cover this — documented as detached-only, whereas large_output_file_path is on the attached read path.
• Related but distinct: #2984 (session-state trace logging for replay/forensics — different consumer and timing; neither request satisfies the other). The largeOutput issues on copilot-sdk (#1788, #2158, #2161) concern the config not being honored; here it was honored.

從 schemas/api.schema.json 中的 TaskShellProgress 定義開始，接著檢查 rpc.d.ts 的產生路徑，該檔案標記為由該 schema 產生。確認選用欄位的表示方式，並檢查相關的 CLI schema 或 API 驗證測試。完成標準是：附加工作項目的進度在可用時能夠提供大型輸出的路徑和總位元組數，同時不破壞現有的 consumer。