Update tasks docs for the Extensions.Tasks API move

The Tasks feature moved from ModelContextProtocol.Core to the new
ModelContextProtocol.Extensions.Tasks package, which renamed several
types and members. Updated docs/concepts/tasks/tasks.md and the task
references in docs/concepts/stateless/stateless.md so the docfx cross
references resolve and the samples match the current API:

- Types moved to the ModelContextProtocol.Extensions.Tasks namespace.
- Server enablement uses WithTasks(IMcpTaskStore) instead of the removed
  McpServerOptions.TaskStore property.
- Custom tool handlers use CallToolWithAlternateHandler returning
  ResultOrAlternate<CallToolResult>.
- Task scope uses the McpTasksServerExtensions.CreateMcpTaskScope
  extension.
- Client calls use CallToolWithPollingAsync, CallToolAsTaskAsync, and the
  Get/Update/CancelTaskAsync client extensions; the stuck-poll threshold
  is now the maxConsecutiveStuckPolls parameter.

Author: Tarek Mahmoud Sayed

docs/concepts/stateless/stateless.md

@@ -590,7 +590,7 @@ In stateless mode, each HTTP request creates and disposes a short-lived `McpServ
 
 ## Tasks and session modes
 
-[Tasks](xref:tasks) enable a "call-now, fetch-later" pattern for long-running tool calls. Task support depends on having an <xref:ModelContextProtocol.Server.IMcpTaskStore> configured (`McpServerOptions.TaskStore`), and behavior differs between session modes.
+[Tasks](xref:tasks) enable a "call-now, fetch-later" pattern for long-running tool calls. Task support depends on having an <xref:ModelContextProtocol.Extensions.Tasks.IMcpTaskStore> configured (enabled via `WithTasks`), and behavior differs between session modes.
 
 ### Stateless mode
 
@@ -600,9 +600,9 @@ In stateless mode, there is no `SessionId`, so the task store does not apply ses
 
 ### Stateful mode
 
-In stateful mode, the `IMcpTaskStore` receives the session's `SessionId` on every operation — `CreateTaskAsync`, `GetTaskAsync`, `ListTasksAsync`, `CancelTaskAsync`, etc. The built-in <xref:ModelContextProtocol.Server.InMemoryMcpTaskStore> enforces session isolation: tasks created in one session cannot be accessed from another.
+In stateful mode, the `IMcpTaskStore` receives the session's `SessionId` on every operation: `CreateTaskAsync`, `GetTaskAsync`, `ListTasksAsync`, `CancelTaskAsync`, etc. The built-in <xref:ModelContextProtocol.Extensions.Tasks.InMemoryMcpTaskStore> enforces session isolation: tasks created in one session cannot be accessed from another.
 
-Tasks can outlive individual HTTP requests because the tool executes in the background after returning the initial `CreateTaskResult`. Task cleanup is governed by the task's TTL (time-to-live), not by session termination. However, the `InMemoryMcpTaskStore` loses all tasks if the server process restarts. For durable tasks, implement a custom <xref:ModelContextProtocol.Server.IMcpTaskStore> backed by an external store. See [Implementing a custom task store](xref:tasks#implementing-a-custom-task-store) for guidance.
+Tasks can outlive individual HTTP requests because the tool executes in the background after returning the initial `CreateTaskResult`. Task cleanup is governed by the task's TTL (time-to-live), not by session termination. However, the `InMemoryMcpTaskStore` loses all tasks if the server process restarts. For durable tasks, implement a custom <xref:ModelContextProtocol.Extensions.Tasks.IMcpTaskStore> backed by an external store. See [Implementing a custom task store](xref:tasks#implementing-a-custom-task-store) for guidance.
 
 ### Task cancellation vs request cancellation
 
@@ -654,7 +654,7 @@ The `EventStreamStore` itself has TTL-based limits (default: 2-hour event expira
 
 ### With tasks (experimental)
 
-[Tasks](xref:tasks) are an experimental feature that enables a "call-now, fetch-later" pattern for long-running tool calls. When a client sends a task-augmented `tools/call` request, the server creates a task record in the <xref:ModelContextProtocol.Server.IMcpTaskStore>, starts the tool handler as a fire-and-forget background task, and returns the task ID immediately — the POST response completes **before the handler starts its real work**.
+[Tasks](xref:tasks) are an experimental feature that enables a "call-now, fetch-later" pattern for long-running tool calls. When a client sends a task-augmented `tools/call` request, the server creates a task record in the <xref:ModelContextProtocol.Extensions.Tasks.IMcpTaskStore>, starts the tool handler as a fire-and-forget background task, and returns the task ID immediately, so the POST response completes **before the handler starts its real work**.
 
 This means: