[.NET 1.0.6][FFI] CreateSessionAsync can hang after successful startup in Linux/Kubernetes

## Summary

With the .NET SDK 1.0.6 in-process transport (`RuntimeConnection.ForInProcess()`), `CopilotClient.StartAsync()` succeeds, but a later `CreateSessionAsync()` can remain incomplete indefinitely in a Linux container running on Kubernetes.

The same application/configuration works locally, and changing only the replacement transport from FFI to the default stdio child-process transport recovers session creation.

## Environment

- GitHub Copilot SDK for .NET: 1.0.6
- Runtime: .NET 8
- Host: Linux container on Kubernetes
- Client mode: `CopilotClientMode.Empty`
- Transport: `RuntimeConnection.ForInProcess()`
- Session uses a custom provider, tools/hooks, and `SessionFs`

## Observed behavior

1. Create the client with `RuntimeConnection.ForInProcess()`.
2. `StartAsync()` completes successfully and the transport reports setup complete.
3. Call `CreateSessionAsync(sessionConfig)`.
4. The returned task never completes or faults. The API has no cancellation token, so the caller cannot stop it.
5. Recreating another client with the same FFI transport can reproduce the wedge.
6. Recreating the client with `Connection = null` (stdio) allows the same session configuration to succeed.

Representative host-side timeout logs:

```text
CreateSessionAsync did not return within 120000ms; abandoning session creation. The SDK transport is likely wedged.

Create failed with a dead/wedged transport; recreating the Copilot client and retrying once.
```

We also observed that disposal of sessions/client associated with the wedged FFI transport may not complete promptly, so recovery must not depend on unbounded `DisposeAsync()` calls.

## Expected behavior

`CreateSessionAsync()` should either:

- complete successfully,
- fail with a transport/runtime exception, or
- accept cancellation/a timeout so the host can recover.

If the in-process runtime becomes unhealthy after startup, recreating the client should not recreate the same permanently wedged runtime state.

## Current workaround

We keep FFI as the preferred transport, but on the first post-start session-create/send transport timeout:

1. mark the FFI transport unhealthy,
2. detach sessions associated with that client generation,
3. bound/abandon cleanup of the wedged runtime,
4. recreate the client with stdio, and
5. retry once with a rebuilt session configuration.

## Related issue

#1934 tracks options/environment parity for the in-process transport. This appears distinct: startup succeeds, but the FFI transport later stops completing session operations.

Please let me know what additional native/runtime logging or a smaller container repro would be most useful.

Start by reproducing the .NET SDK 1.0.6 case in a Linux/Kubernetes container, using RuntimeConnection.ForInProcess(), StartAsync(), and CreateSessionAsync(); compare it with the default stdio transport. Trace the in-process transport after startup and capture native/runtime logs around session creation and disposal. Done means the operation completes or reports a bounded failure, with a documented recovery path that does not depend on unbounded cleanup.

Vom Indexierungsmodell aus dem Issue-Text verfasst.