Persist client_type / agentContext in session-state files

### Describe the feature or problem you'd like to solve

Session-state files don't capture how a session was launched (interactive vs SDK) or which app created it

### Proposed solution

The CLI already tracks `client_type` (e.g., `"cli-interactive"`, `"cli-prompt"`, `"sdk"`, `"cli-acp"`) and `agentContext` (`"cli"`, `"cca"`, `"sdk"`) at runtime and includes them in Hydro telemetry via `ClientInfo`. However, neither field is persisted to the local session-state files (`workspace.yaml` or the `session.start` event in `events.jsonl`).

Adding `client_type` (and/or `agentContext`) to the persisted session metadata would let users and tooling distinguish interactive CLI sessions from SDK/app-triggered sessions locally, without needing access to Hydro.

Ideally, SDK consumers should also be able to assign their own application identifier (e.g., `clientName`) that gets persisted alongside `client_type`. The SDK already accepts `clientName` in `SessionConfig`, but it's only used in the User-Agent header — not written to session-state files. Persisting it would let teams running multiple SDK-based tools (e.g., a CI bot, a code reviewer, a migration script) distinguish their sessions from each other, not just from interactive CLI usage.

### Example prompts or workflows

1. A user builds a session archiver/dashboard on top of `~/.copilot/session-state/` and wants to filter out single-prompt SDK calls from multi-turn interactive work to get accurate usage metrics.
2. A team uses the copilot-sdk to trigger automated tasks and wants to segment analytics — but the persisted `workspace.yaml` and `session.start` event only contain `host_type` (git provider), not how the session was launched.
3. An extension author wants to react differently to SDK vs interactive sessions in a `sessionStart` hook, but `SessionStartHookInput` only exposes `sessionId`, `cwd`, `timestamp`, and `source` — not `client_type` or `agentContext`.
4. A team runs three SDK-based tools (a CI bot, a code reviewer, a migration script) — all show up identically in session history. Persisting `clientName` alongside `client_type` would let them attribute sessions to specific tools.

### Additional context

Today the only persisted differentiator is `host_type` (`"github"` / `"ado"` / absent), which identifies the git hosting provider — not the session launch mode. You can try heuristics (single `user.message` = probably SDK, `baseCommit` present = probably coding agent), but these overlap with short interactive sessions and are unreliable.

The values already exist at runtime; they'd just need to be serialized. Possible locations:
- `session.start` event in `events.jsonl` (alongside the existing `context` object)
- `workspace.yaml` (alongside `host_type`)
- `SessionStartHookInput` (so extensions can capture it)