Provide a durable turn-completion signal for resumed sessions

## Summary

When a client resumes or reconnects after missing the live event stream, there does not appear to be a documented way in the CLI/SDK to query whether the previous turn already completed successfully.

`session.idle` appears to be the canonical live "turn is done / session is now idle" signal, but because it is ephemeral and not persisted to `events.jsonl`, a reconnecting client that missed it has to infer completion from persisted artifacts and coarse session metadata.

## Current situation

A resumed client can currently combine:

- live events, **if** it was attached when they arrived,
- session metadata such as `ModifiedTime`, and
- persisted artifacts such as `~/.copilot/session-state//events.jsonl`.

However, none of the documented SDK APIs seem to provide a direct answer to: **did the previous turn already finish, or is it still in progress?**

For example:

- `GetStatusAsync()` exposes CLI/protocol status, not per-session turn state
- `ListSessionsAsync()` / `GetSessionMetadataAsync()` expose metadata, not turn completion state
- `assistant.turn_end` is persisted, but is not a reliable terminal signal because it can occur between tool rounds

## Why this matters

For restart/reconnect flows, clients need an authoritative answer to whether the last turn finished cleanly.

Without that, they have to resort to heuristics such as:

1. scanning the tail of `events.jsonl`,
2. checking file mtime / file growth, and
3. waiting on timeout/watchdog logic.

Those heuristics are inherently unreliable for long-running or tool-heavy turns and can produce both false positives and false negatives.

## Requested improvement

Any of the following would solve the underlying problem:

1. **Persist a durable completion marker to `events.jsonl`** — either by persisting the final `session.idle`, or by emitting a dedicated persisted event such as `session.turn_complete`
2. **Expose a documented session/turn status API** that a reconnecting client can call after resume
3. **Persist a final session status snapshot** that can be read after reconnect

The important point is not the exact mechanism; it is that resumed clients need some **authoritative, durable completion signal** instead of having to guess.

## Scope

- Affects the CLI event log under `~/.copilot/session-state//events.jsonl`
- Affects SDK/app clients that restore or reconnect sessions after restart, reconnect, or crash recovery

---

**Related downstream tracking issue:** https://github.com/PureWeen/PolyPilot/issues/538

Start by tracing the documented session APIs, including GetStatusAsync(), ListSessionsAsync(), and GetSessionMetadataAsync(), alongside the persisted events.jsonl log and session.idle handling. Determine which durable mechanism can answer whether the previous turn completed after reconnect; done means a resumed client can obtain an authoritative completion result without tail-scanning, mtime checks, or watchdog timeouts.

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