[Client] SEP-2663 Tasks: Poll task handles and answer inputRequests

Client side of SEP-2663 for the 2026-07-28 release. Tracked by umbrella #335. Follows the server side (#345–#348).

Scope

• Client\Builder::enableExtension(new TasksExtension()) declares io.modelcontextprotocol/tasks in the initialize request (no store needed on the client).
• Mcp\Client\Task\TaskClient wraps a connected Client (the core client stays task-agnostic; it gains a generic Client::request()): callTool() / getPrompt() / readResource() return a CreateTaskResult when the server answered with resultType: "task"; get() polls tasks/get and returns the Task (status, statusMessage, pollIntervalMs, result once completed, error once failed, inputRequests while waiting); update() answers inputRequests through tasks/update; cancel().
• The polling loop and routing inputRequests to the application's elicitation/sampling handlers stay application code; Task::fromArray() reads the wire shape.
• End-to-end coverage in tests/Integration/TasksTest against a stdio fixture server.

Notes

The server exposes pending asks on tasks/get and takes answers on tasks/update; that is the SEP-2260 request-scoping the original sketch of this issue described, without piggybacking anything on the tasks/update response.

Inizia con Client\Builder::enableExtension(), il Client::request() generico e l’API TaskClient descritta nell’issue. Usa tests/Integration/TasksTest e il relativo fixture stdio come primo punto di validazione. Il lavoro è completo quando le richieste compatibili con i task restituiscono CreateTaskResult, TaskClient supporta get, update e cancel e Task::fromArray() legge la struttura wire senza aggiungere polling o routing degli handler.