.NET: Discuss provider-agnostic conversation creation API

## Summary

Issue #2931 is being addressed first with a Python `FoundryAgent` convenience method that mirrors the existing .NET FoundryAgent conversation-session API. A broader provider-agnostic conversation creation API should be designed separately and in sync across Python and .NET before implementation.

## Problem

Some providers expose server-side conversation/session creation, but application code currently has to reach into provider SDKs to create those conversations. A framework-level abstraction could reduce provider coupling, but it would need to align across languages and avoid confusing local `AgentSession.session_id` with provider continuation state.

## Scope to discuss

- Whether Agent Framework should expose a provider-agnostic conversation/session creation API.
- What the API shape should be in Python and .NET.
- How created provider conversation IDs should map onto `AgentSession` state.
- How this relates to service-managed history, A2A `context_id`/`task_id`, AG-UI `thread_id`/`run_id`, and telemetry correlation.

## Non-goals for the first Python fix

- Do not block the direct Python `FoundryAgent` method for #2931.
- Do not introduce a Python-only provider-agnostic facade before syncing with .NET.

Related: #2931, #4673, #4893.

Start by reading #2931 and the existing .NET FoundryAgent conversation-session API referenced in the issue, then compare the related concerns in #4673 and #4893. The discussion is done when Python and .NET agree on a provider-agnostic API shape and clearly define how provider conversation IDs map to AgentSession state.

Written by the indexing model from the issue text.