Persist client_type / agentContext in session-state files

[Arithmomaniac]

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)