Feature request: allow seeding a new session with conversation history

Inizia dagli entry point SessionConfig, CreateSessionAsync e SendAsync indicati nella richiesta, quindi segui come viene inizializzato lo stato della conversazione della sessione. Il lavoro è completato quando i chiamanti possono fornire coppie ruolo/contenuto di utente e assistente tramite InitialMessages prima del primo SendAsync e il modello le tratta come cronologia della conversazione.

Problem

The Copilot SDK uses a session-based model where the session owns the conversation state. This works well when the SDK controls the full conversation lifecycle, but doesn't fit applications that manage conversation history externally. An example is applications that allow the user or harness to rewind, edit, condense or restructure prior turns.

In these cases, the only option is to format prior messages into the prompt text with role markers like [User] / [Assistant] and explain the convention in the system message. This works but is far from ideal, because the model may not treat text labeled as its own prior output with the same status as actual assistant-role messages, and creates confusion if the user's text includes what could be interpreted as unbalanced delimiters (such as ``` without a closing fence).

The SDK's session resumption feature (ResumeSessionAsync) doesn't help here because the caller needs to be able to arbitrarily reshape the history on every turn.

Proposed solution

Add an InitialMessages property to SessionConfig - a list of role/content pairs that seed the session's conversation history before the first SendAsync call:

var session = await client.CreateSessionAsync (new SessionConfig
{
    InitialMessages = new List<SessionMessage>
    {
        new ("user", "Explain async/await in C#"),
        new ("assistant", "Async/await is a pattern for..."),
    },
    // ...
}); 

The messages would be treated as real conversation history by the model - not as text stuffed into a user prompt.

Note that the history seed doesn't necessarily have to support every feature of every kind of message. Simply having the ability to specify the role (user/assistant) and text would be incredibly useful.