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

Comienza con Client\Builder::enableExtension(), el Client::request() genérico y la API de TaskClient descrita en el issue. Usa tests/Integration/TasksTest y su fixture de stdio como primer punto de validación. Se considera terminado cuando las solicitudes capaces de usar tareas devuelven CreateTaskResult, TaskClient admite get, update y cancel, y Task::fromArray() lee la estructura wire sin añadir polling ni enrutamiento de handlers.