feat(mcp): add MRTR input flows and Tasks for long-running intelligence work

## Summary\n\nAdd the MCP 2026-07-28 interaction primitives WorldMonitor needs for safe missing-input/confirmation flows and durable long-running intelligence operations.\n\nDepends on #5817. Do not make either extension a hard dependency while Claude/client support is still rolling out.\n\nReferences:\n- https://blog.modelcontextprotocol.io/posts/2026-07-28/#multi-round-trip-requests-mrtr\n- https://modelcontextprotocol.io/extensions/tasks/overview\n\n## Product fit\n\nMRTR is useful when a request is missing a country, date, ticker, airport, analysis scope, or confirmation for a costly live generation. Tasks fit operations that can outlive one HTTP request, including:\n- generate_forecasts;\n- analyze_situation;\n- backtests;\n- report generation;\n- bounded bulk or durable-history analysis.\n\nFast seeded/cache tools should remain synchronous.\n\n## Scope\n\n### Multi Round-Trip Requests\n\n- Return resultType: input_required with bounded inputRequests when a compatible client must supply missing input, choose among ambiguous scopes, or confirm a clearly identified costly/high-impact operation.\n- Accept inputResponses only when they correspond to the original request and declared input IDs.\n- Re-run authorization, entitlement, quota, and argument validation on continuation.\n- Provide ordinary structured error/help fallbacks for clients that do not advertise MRTR support.\n- Do not use MRTR merely to compensate for weak tool schemas or descriptions.\n\n### Tasks extension\n\n- Negotiate io.modelcontextprotocol/tasks before returning task handles.\n- Start with one demonstrably long-running workflow selected from production latency/timeout evidence.\n- Durably create the task before returning its opaque, unguessable, authorization-scoped ID.\n- Implement tasks/get, tasks/update for mid-flight input, cooperative tasks/cancel, TTL, and a bounded poll interval.\n- Keep terminal task state stable and idempotent across retries.\n- Ensure a user/tenant cannot enumerate, read, update, or cancel another principal's task.\n- Integrate task lifecycle, result provenance/freshness, quota reservation/refund policy, billing denial, telemetry, and error fingerprints.\n\n## Acceptance criteria\n\n- [ ] MRTR works only for clients advertising support and degrades cleanly for other clients.\n- [ ] Continuations cannot bypass auth, entitlement, quota, validation, or idempotency.\n- [ ] At least one evidence-backed long-running tool completes through the Tasks lifecycle.\n- [ ] tasks/get, tasks/update, and tasks/cancel enforce principal and tenant ownership.\n- [ ] Task creation is durable before the handle is returned; retries do not create duplicate billable work.\n- [ ] Terminal success/failure/cancellation states remain stable until the documented TTL.\n- [ ] Existing synchronous behavior remains available for fast tools.\n- [ ] Tests cover disconnect/retry, duplicate continuation, expired task, cross-user access, cancellation races, billing uncertainty, and unsupported clients.\n- [ ] MCP docs, tools reference, error catalog, and telemetry schema describe the new lifecycle.\n\n## Non-goals\n\n- Converting every live tool to a task.\n- Adding new mutating external-system tools.\n- Replacing existing background infrastructure before one workflow proves the extension's value.

Start with dependency #5817 and the MCP MRTR and Tasks references, then locate the existing MCP tool handlers, authorization checks, and background-work infrastructure. Trace one production workflow suitable for Tasks before designing the lifecycle. Done means the selected workflow supports negotiated MRTR or clean fallback, durable ownership-checked task operations, stable terminal states, and the listed retry, cancellation, billing, and unsupported-client tests.

Written by the indexing model from the issue text.