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?

Start with the existing SessionConfigBase session configuration and the CLI 1.0.83 skillProvider.list/read callbacks, using github/copilot-sdk#2494 for context on the generated handler surface. Done means reaching maintainer agreement on a public, session-scoped provider API and its compatibility and language-parity requirements before implementation.

Vom Indexierungsmodell aus dem Issue-Text verfasst.