Stateless createMcpHandler: support the MCP Tasks extension (SEP-2663, io.modelcontextprotocol/tasks)

### Summary

The 2026-07-28 MCP revision promotes Tasks to an official extension — [`io.modelcontextprotocol/tasks`](https://modelcontextprotocol.io/extensions/tasks/overview) ([SEP-2663](https://modelcontextprotocol.io/seps/2663-tasks-extension)): `tasks/get` polling, `tasks/cancel`, task-augmented requests. The schemas already ship in `@modelcontextprotocol/server` 2.0.0 (`ServerTasksCapability`, `TaskAugmentedRequestParams`).

As of `agents@0.21.0`, the stateless `createMcpHandler` path has no tasks wiring — `tasks/get` appears nowhere in the dist, and the migration guide lists published tasks as unsupported on the stateless path. I couldn't find an existing issue tracking this, so filing one.

### Use case

We run the recommended dual-lane setup in production (deprecated `McpAgent` for legacy clients beside the stateless handler for 2026-07-28 clients): a hosted human-in-the-loop approvals server, where an agent requests an approval and a human decides later — minutes or days. Today that's a bespoke long-poll trio (`await`/`status`/`result` tools) over an authoritative DB record. Tasks is the official primitive for exactly this shape, and the DB-backed poll is a natural fit for the stateless path: `tasks/get` maps to a database read, no session or Durable Object required.

### Questions

1. Is stateless-path Tasks support on the roadmap for `createMcpHandler`?
2. Is there a design constraint (no session identity on the stateless path?) that blocks it, or is it just not built yet? A handler hook where the app resolves a task id to `{status, result}` from its own store would cover our case entirely.

Happy to share more requirements from the production use case.