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

Bắt đầu bằng cách lần theo các API phiên đã được ghi lại, bao gồm GetStatusAsync(), ListSessionsAsync() và GetSessionMetadataAsync(), cùng với nhật ký events.jsonl đã được lưu bền vững và cách xử lý session.idle. Xác định cơ chế bền vững nào có thể trả lời liệu lượt trước đã hoàn tất sau khi kết nối lại hay chưa; hoàn tất nghĩa là client được tiếp tục có thể nhận kết quả hoàn tất có tính xác thực mà không cần quét phần cuối nhật ký, kiểm tra mtime hoặc dùng watchdog timeout.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.