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

Start with Client\Builder::enableExtension(), the generic Client::request(), and the TaskClient API described in the issue. Use tests/Integration/TasksTest and its stdio fixture as the first validation point. Done means task-capable requests return CreateTaskResult, TaskClient supports get, update, and cancel, and Task::fromArray() reads the wire shape without adding polling or handler routing.