AHP 1.0 createSession does not emit session/ready until the first turn

- Copilot Chat Extension Version: N/A (built-in Agent Host)
- VS Code Version: 1.135.0 (`08d4889f9ec4a1685d257b9b95de036c8e1ce1e5`)
- OS Version: Linux remote container; macOS client
- Feature: Agent Host Protocol 1.0 session lifecycle
- Selected model: GPT-5.6 Sol
- Logs: Sanitized action sequence included below

## Steps to reproduce

1. Start a standalone Agent Host with fresh isolated user/server data.
2. Negotiate AHP 1.0 and authenticate the Copilot protected resources.
3. Call `resolveSessionConfig` for a valid working directory.
4. Call `createSession` with a new client-chosen `ahp-session:/`, provider `copilotcli`, working directory, valid config, and an `activeClient` matching the initializing client ID.
5. Subscribe to the exact session resource.
6. Wait for `session/ready` or `session/creationFailed`.

## Actual

The session snapshot remains:

```text
lifecycle: creating
```

It already contains:

- a valid server-generated `defaultChat`
- the same chat in `SessionState.chats`

But no `session/ready` or `session/creationFailed` arrives. The only session actions observed during the wait are `session/metaChanged`.

This remained unchanged with and without `activeClient`.

If the client violates the normative ordering and sends a neutral first turn to the advertised default chat anyway:

1. the chat turn completes;
2. a fresh session snapshot then reports `lifecycle: ready`.

## Expected

Per the AHP 1.0 session lifecycle, the host should emit `session/ready` after backend initialization, before the client needs to start a turn.

Clients should not need to send a first turn to make the session become ready, because the documented flow requires waiting for readiness before using the session.

## Impact

Strict AHP 1.0 clients deadlock:

- the host waits for a first turn to materialize the backend;
- the client waits for `session/ready` before sending that turn.

The only workaround is a VS Code-specific bounded exception: when lifecycle is still `creating` but a valid default chat is already catalogued, send a neutral materializing turn and then require a fresh session snapshot to become `ready`.

## Related, but not duplicate

- #331118 covers a first-turn customization refresh that leaves an active turn permanently stuck.

This report is about the earlier session-lifecycle transition: no turn has been sent yet, and `session/ready` is withheld until one is sent.