Add SEP-2663 Tasks Extension conformance scenarios

[panyam]

Proposal

Add server-conformance scenarios for SEP-2663 (Tasks Extension), with incidental coverage of SEP-2575 (per-request
capability override) and SEP-2243 (Mcp-Method/Mcp-Name request headers) in the parts of the surface where they bind to
tasks. Plus one new MRTR-adjacent check (mrtr-tasks-composition, currently SKIPPED) for the SEP-2663 commit 451f5e1
MRTR→Tasks promotion flow.

Tagged ['extension', DRAFT_PROTOCOL_VERSION] per #255 conventions.

Implementation: Draft PR (link to be added after open) from panyam/mcpconformance:feat/tasks-mrtr-extension. 8
ClientScenario classes / ~33 checks for tasks plus 1 class / 7 checks + 1 SKIPPED for the MRTR↔Tasks composition
placeholder. Full scope, design notes, and test instructions live in the PR description.

Relationship to PR #188 (SEP-2322 MRTR)

Complementary, not overlapping. SEP-2663 builds on SEP-2322's base types, so a few of the tasks scenarios touch the MRTR
shape (inputRequests, requestState, resultType) in their tasks-on-the-wire form (status:"input_required" on
tasks/get, tasks/update resume path, partial inputResponses fulfillment). The standalone-ephemeral-MRTR coverage stays
in #188.

If #188 lands first (expected order — SEP-2322 ships before SEP-2663), I'll drop the duplicative mrtr-ephemeral-flow.ts
checks in favor of #188's scenarios. The mrtr-tasks-composition check (currently SKIPPED) is the genuinely new
contribution to MRTR coverage — it asserts SEP-2663's MRTR→Tasks promotion flow.

Open spec questions

1. MRTR resultType discriminator value. SEP-2322's draft uses "input_required"; SEP-2663's draft uses
   "incomplete". Centralized in code as MRTR_INCOMPLETE_RESULT_TYPE for a one-line flip when the SEP authors converge.

2. mrtr-tasks-composition. SEP-2663 commit 451f5e1 made the MRTR→Tasks promotion flow normative on the wire: a
   single tools/call MAY exchange one or more IncompleteResult rounds and then return CreateTaskResult on a subsequent
   round. Implementing this requires the server middleware to defer task creation until the handler signals async-promotion —
   the natural alternative (mint the task up-front the moment a tool advertises task support) doesn't fit, because by the
   time the handler's IsIncomplete signal is observable, the CreateTaskResult is already on the wire. This is a
   wire-contract requirement, not an SDK-specific implementation choice; existing SDKs across languages that took the up-front
   pattern will need refactoring before this check can pass anywhere. Combined with Adjust test and allow running in interactive mode #1 above, that's why the check is
   SKIPPED today.