Feature request: allow seeding a new session with conversation history

Bắt đầu với các điểm vào SessionConfig, CreateSessionAsync và SendAsync được nêu trong yêu cầu, sau đó theo dõi cách trạng thái hội thoại của session được khởi tạo. Được xem là hoàn tất khi bên gọi có thể cung cấp các cặp vai trò/nội dung của user và assistant thông qua InitialMessages trước lần SendAsync đầu tiên, và model coi chúng là lịch sử hội thoại.

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.