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.

Comienza en schemas/api.schema.json, en la definición de TaskShellProgress, y después inspecciona la ruta de generación de rpc.d.ts, que está marcada como generada a partir de ese esquema. Verifica cómo se representan los campos opcionales y revisa las pruebas relevantes del esquema de CLI o de validación de API. La tarea estará terminada cuando el progreso de las tareas adjuntas pueda exponer la ruta de la salida grande y el recuento total de bytes cuando estén disponibles, sin romper los consumidores existentes.