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.

Beginne in schemas/api.schema.json bei der Definition von TaskShellProgress und untersuche anschließend den Generierungspfad für rpc.d.ts, der als aus diesem Schema generiert markiert ist. Prüfe, wie optionale Felder dargestellt werden, und sieh dir die relevanten CLI-Schema- oder API-Validierungstests an. Erledigt ist die Aufgabe, wenn der Fortschritt angehängter Tasks bei Verfügbarkeit den Pfad zur großen Ausgabe und die Gesamtanzahl der Bytes bereitstellen kann, ohne bestehende Consumer zu beeinträchtigen.