Expose session-scoped in-memory skill providers

## Use case

An SDK host may manage reusable skills in its own data store rather than in a project directory. We would like those skills to participate in Copilot's normal skill catalog and native `skill` tool, alongside file-based skills, without:

- materializing and synchronizing `SKILL.md` files;
- registering a second skill-loading tool;
- replacing the native skill tool and reimplementing its fallback/activation behavior.

Custom agents and MCP servers already have programmatic session configuration; skill content currently has no equivalent public provider in the .NET SDK.

## Existing runtime support

The published CLI 1.0.83 protocol already contains the internal/experimental `skillProvider.list` and `skillProvider.read` callbacks and the `hasSkillProvider` session flag. It identifies these as lazy, pathless, text-only SDK skills. The .NET SDK does not expose the corresponding handwritten session registration API.

I understand that keeping these transport callbacks out of the generated public handler surface is intentional: see github/copilot-sdk#2494. This proposal is for a small, idiomatic public facade, not for making the raw internal callbacks public or changing the generator.

## Proposed behavior for discussion

- An optional session-scoped provider lists skill metadata and reads complete Markdown on demand.
- Register the provider before create/resume so early runtime callbacks can be handled.
- The native `skill` tool performs activation; no extra tool or native-tool override.
- Re-supply the provider on resume; it is not serialized into session history.
- Leave sessions without a provider unchanged.
- Respect `EnableSkills = false`, native invocation flags, cancellation, and session ownership.
- Keep this text-only: no asset provider, virtual filesystem, or new storage layer.

A possible .NET shape is an experimental `SessionConfigBase.SkillProvider` backed by asynchronous `ListAsync` and `ReadAsync` methods. The exact API and cross-language equivalents should be aligned with the maintainers.

## Investigation and prototype

A local prototype using the existing CLI 1.0.83 runtime has exercised:

- lazy native activation without skill directories;
- coexistence with native file-based skills;
- create/resume binding and reloading updated content;
- native subagent invocation and assigned-skill preloading;
- source-generated .NET JSON serialization with reflection disabled.

This is not a claim that the internal protocol is a supported public contract. I would like to confirm whether exposing this capability is on the roadmap and what public API/compatibility policy the team prefers.

## Maintainer alignment

The contribution guide asks for feature discussion before a review-ready implementation and notes the need for language parity. I am opening this proposal first. A linked draft .NET PR can serve as a concrete, tested implementation for discussion; it would not imply that the feature or .NET-only rollout has been agreed.

Would the team be interested in this facade, and is there an existing planned implementation or issue it should align with?

Comienza con la configuración de sesión SessionConfigBase existente y los callbacks skillProvider.list/read de la CLI 1.0.83, usando github/copilot-sdk#2494 como contexto para la superficie de los handlers generados. Se considera terminado cuando se alcance un acuerdo entre los maintainers sobre una API de provider pública y con ámbito de sesión, así como sobre sus requisitos de compatibilidad y paridad de lenguaje, antes de la implementación.

Escrito por el modelo de indexación a partir del texto del issue.