No client-suite scenarios for the tasks extension (io.modelcontextprotocol/tasks)

The server suite has 10 tasks-* scenarios, but the client suite has none. SEP-2663 places normative requirements on clients too — most importantly:

A client that has negotiated this extension MUST be prepared to handle either CallToolResult or CreateTaskResult in response to any supported request it issues.

plus the tasks/get polling flow (pollIntervalMs handling), issuing tasks/update / tasks/cancel, and the Mcp-Name: <taskId> routing header on tasks/* requests.

python-sdk is landing a client-side transparent polling driver (modelcontextprotocol/python-sdk#3005) and currently has no way to verify it against the harness — client conformance can't observe any of the above.

Suggested client-suite scenarios:

• tasks-client-create-handling — the harness server task-augments a tools/call; the client must handle the CreateTaskResult and fetch the result via tasks/get.
• tasks-client-poll-interval — the client honors pollIntervalMs between polls.
• tasks-client-routing-headers — the client stamps Mcp-Name: <taskId> on tasks/* POSTs.
• tasks-client-terminal-handling — failed / cancelled tasks are surfaced rather than polled forever.

_{AI Disclaimer}

Start by reading SEP-2663 and the existing server-suite tasks-* scenarios, then locate the client-suite scenario definitions and harness flow. Add coverage for CreateTaskResult handling, pollIntervalMs, Mcp-Name routing, and failed or cancelled terminal tasks; done means the client suite exercises all four behaviors.