[FEATURE][CF-DATAPLANE][TASKS]: Forward server-directed task results from tools/call

[lucarlig]

Part of #5683.

Blocked by

• [Major-1] Dual-stack stateless core protocol #5679 — per-request client metadata and modern stateless backend lifecycle.
• [Major-4] Multi Round-Trip Requests (MRTR) and required resultType #5682 — the shared CallToolResponse / required-resultType path.
• [Minor-6] Extensions capability field + OpenTelemetry _meta propagation #5689 — extension capability negotiation and advertisement.
• [FEATURE][CF-DATAPLANE][TASKS]: Add stateless backend-scoped task handles #6185 — stateless backend-scoped task handles.

Scope

Implement this in the Rust dataplane repository (contextforge-org/contextforge-data-plane) for MCP 2026-07-28 only.

The current dataplane backend path accepts only ServerResult::CallToolResult; an upstream CreateTaskResult is treated as an unexpected response. Modern task-capable upstreams must be able to choose asynchronous execution when the downstream request declares io.modelcontextprotocol/tasks.

Work

• Change backend tool-call forwarding to preserve RMCP's complete, MRTR, and task-aware response union after [Major-4] Multi Round-Trip Requests (MRTR) and required resultType #5682 establishes the shared response path.
• Accept an upstream CreateTaskResult only for the currently supported task-augmented method, tools/call.
• Rewrite the upstream taskId using [FEATURE][CF-DATAPLANE][TASKS]: Add stateless backend-scoped task handles #6185 before returning the task handle downstream.
• Preserve resultType, status, timestamps, ttlMs, pollIntervalMs, and result metadata.
• Enforce per-request client capability gating; never return a task handle to a request that did not declare io.modelcontextprotocol/tasks.
• Define fail-closed CPEx/plugin behavior so deferred results do not silently bypass configured post-call policy.
• Update the request-flow and MCP method documentation.

Acceptance criteria

• A task-capable client can receive either a normal CallToolResult or a server-directed CreateTaskResult.
• The exposed task handle routes to the originating backend without revealing the raw upstream task ID.
• A client without the Tasks extension never receives resultType: "task" and gets the protocol-required missing-capability error when a task is required.
• Existing synchronous and MRTR tool-call behavior remains intact.
• Task-handle responses do not trigger completed-result plugin hooks with the wrong payload, and configured policy is not silently skipped.
• Focused tests cover synchronous, MRTR, task, missing-capability, plugin-policy, and backend-error cases.

Out of scope

• Python control-plane task handling or legacy protocol translation.
• Gateway-managed polling.
• tasks/list and tasks/result.