session.shutdown event should persist the reason from SessionEndHookInput

### Problem

The runtime internally tracks session end reason via `SessionEndHookInput.reason`, but the `session.shutdown` event persisted to `events.jsonl` only records `shutdownType: "routine" | "error"`. That collapses several distinct non-error causes into the single label `"routine"` and makes post-hoc diagnosis of session lifecycle incidents much harder than it needs to be.

From the installed 1.0.32 type definitions:

```typescript
// sdk/index.d.ts
export declare interface SessionEndHookInput extends BaseHookInput {
reason: "complete" | "error" | "abort" | "timeout" | "user_exit";
finalMessage?: string;
error?: Error;
}

// sdk/index.d.ts
shutdown(shutdownType?: "routine" | "error", errorReason?: string): void;

// copilot-sdk/generated/session-events.d.ts
data: {
shutdownType: "routine" | "error";
errorReason?: string;
// ... usage metrics
}
```

So the runtime appears to have more granular reason information available internally, but the persisted shutdown event does not keep it.

### Concrete impact

In one 1.0.32/Linux session, I observed two `session.shutdown` events with `shutdownType: "routine"` that had materially different provenance:

| Shutdown | Provenance visible from nearby events |
| --- | --- |
| 1st | preceded by an `abort` event with `reason: "user initiated"`, resumed 18 seconds later |
| 2nd | no preceding abort, interrupted active tool execution, bash subprocess received SIGTERM / exit 143 163 ms later, resume happened 2h 44m later |

At the `session.shutdown` event level, those two cases are indistinguishable even though the surrounding event stream shows they are not the same kind of lifecycle transition.

### Context for the second shutdown

Single incident; not claiming a reproducible bug. Parameters at the time of the disruptive shutdown:

| Metric | Value |
| --- | --- |
| Copilot CLI | 1.0.32 |
| OS | Linux |
| Session age | 6h 12m 49.578s |
| Time since last user message | 5h 24m 08.244s |
| events.jsonl size through shutdown line | 45,016,499 bytes / 11,691 lines |
| `task` tool launches before shutdown | 40 |
| Cumulative API duration | 38,889,407 ms (~10.8h) |

I am **not** claiming the shutdown itself was necessarily a bug. It may have been policy, host lifecycle, resource pressure, or something else. The issue here is that the persisted shutdown event does not retain enough reason information to let users or maintainers tell which.

### Request

Please persist the internal session-end reason (or equivalent) into `session.shutdown` events. Even a small additive field would help a lot, for example:

```typescript
data: {
shutdownType: "routine" | "error";
reason?: "complete" | "abort" | "timeout" | "user_exit";
errorReason?: string;
}
```

If the runtime can distinguish other routine-shutdown causes such as external signal receipt or platform/session eviction, a richer optional field would be even better. But even persisting the existing `SessionEndHookInput.reason` values would be a meaningful improvement.

### Why this matters

This would make it much easier to triage session-lifecycle issues without reproducing them live, including cases that currently look similar in raw logs but may have very different causes.

### Related issues

- #2209 — large-session resume failures (different failure mode, same session-lifecycle diagnostic wall)
- #2609 — large-session write-path failures (different failure mode, same session-lifecycle diagnostic wall)
- #2132 — long-session crash under parallel agents (different mechanism: crash/OOM rather than a persisted `session.shutdown`)

### Environment

- Copilot CLI 1.0.32
- Node.js v24.11.1
- Linux x86_64

Comienza con las declaraciones de SessionEndHookInput y shutdown en sdk/index.d.ts, después inspecciona el esquema de eventos de sesión en copilot-sdk/generated/session-events.d.ts y rastrea dónde se escribe session.shutdown en events.jsonl. Determina cómo llega a la persistencia el motivo de finalización existente y actualiza la forma del evento de manera coherente. El trabajo estará terminado cuando los eventos de shutdown conserven el motivo de finalización de sesión aplicable sin perder campos ni comportamiento existentes.

Escrito por el modelo de indexación a partir del texto del issue.