[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.

Commencez par Client\Builder::enableExtension(), le Client::request() générique et l’API TaskClient décrite dans l’issue. Utilisez tests/Integration/TasksTest et son fixture stdio comme premier point de validation. Le travail est terminé lorsque les requêtes compatibles avec les tâches renvoient CreateTaskResult, que TaskClient prend en charge get, update et cancel, et que Task::fromArray() lit la structure wire sans ajouter de polling ni de routage de handlers.