feat(tasks): align scenarios with the Final-merged SEP-2663 spec

[panyam]

What changes

SEP-2663 merged Final on 2026-05-15. Four normative wire changes baked in at merge time were not yet covered by the tasks scenarios in this branch (feat/tasks-mrtr-extension, the source of modelcontextprotocol/conformance PR 262). This PR adds FAIL-on-divergence assertions for each, so the suite validates the merged spec rather than tolerating divergence as INFO/MAY.

The four spec changes:

1. notifications/tasks/status → notifications/tasks.
2. notifications/progress and notifications/message MUST NOT be sent for tasks.
3. requestState removed from the tasks-v2 wire. SEP-2322's InputRequiredResult on the MRTR surface still carries it and is unchanged.
4. -32003 (Missing Required Client Capability) for tools whose task support is required when the client did not negotiate the extension.

Reviewer's guide

Read in this order:

1. src/scenarios/server/tasks/notifications.ts — start here. The status-notifications scenario grew from 1 check to 5: new wire method name (FAIL on the legacy method); absence-asserts for notifications/progress and notifications/message on task streams; the existing shape check on the new method's payloads; and an absence-assert for requestState on notification payloads (reuses the SSE-observation buffer so the harness isn't duplicated in request-state.ts).
2. src/scenarios/server/tasks/request-state.ts — full rewrite. The prior file tested the deleted "Request State Management" section; replaced with absence-asserts on CreateTaskResult and the tasks/get DetailedTask response. Scenario class renamed TasksRequestStateScenario → TasksRequestStateRemovalScenario.
3. src/scenarios/server/tasks/required-task-error.ts — new file. Scenario TasksRequiredTaskErrorScenario initializes a client without declaring the tasks extension, calls a TaskSupport=required tool, and asserts the rejection code is -32003 plus the structured requiredCapabilities.extensions[...] shape. Documents failing_job as a fixture requirement.
4. src/scenarios/server/tasks/all-scenarios.test.ts and src/scenarios/index.ts — registry updates. The renamed scenario class and new scenario class are added to both runners; src/scenarios/index.ts also has a stale "SEP is still in draft" comment swept to current framing since the area was already being touched.

Skim or skip: nothing — every file is load-bearing for the alignment.

Decision log

• FAIL on divergence, not INFO on miss. The prior status-notifications scenario emitted INFO when no notifications were received, which made the rename invisible to the suite. The post-merge spec language is normative: when a server emits the legacy method name on the v2 surface, that is FAILURE. INFO is retained only when an absence-assert is genuinely not exercisable (e.g. no notifications/tasks observed, so the no-requestState-in-notif check has nothing to inspect).
• Reused the notifications.ts SSE-observation harness for the requestState absence-assert on notification payloads. Duplicating the raw fetch + SSE parsing in request-state.ts would have made future SSE-harness changes a 2-file edit; the absence-assert is a few lines once the buffer exists.
• failing_job as fixture name, matching panyam/mcpkit's examples/tasks-v2. Other implementations adopting the suite need to expose a tool registered with task support required; the name is documented in the scenario file's JSDoc fixture block.
• Cited only SEP-2663 on the requestState-removal scenario. The field history is SEP-2322, but the removal is SEP-2663. Only SEP-2663 is cited so a reader doesn't have to triage cross-SEP attribution.

Risk

• This PR is stacked on feat/tasks-mrtr-extension (the source of modelcontextprotocol/conformance PR 262). Merging here updates PR 262's diff to include these scenarios.
• The new assertions intentionally FAIL against the current panyam/mcpkit main. Specifically: panyam/mcpkit still emits requestState on the tasks/get DetailedTask response. The next mcpkit catch-up PR (requestState removal from the v2 wire) closes that gap.
• Other server implementations adopting the suite (everything-server, third parties) will also see FAILUREs until they catch up to the merged spec. That is the intended signal.

Verification

Ran locally against panyam/mcpkit's examples/tasks-v2 fixture (post-rename and post-progress-filter catch-up) via make testconf-tasks-v2: 8 of 9 scenarios pass; only tasks-request-state-removal fails, and only on the tasks-get-detailed-no-request-state check (mcpkit still emits the field on DetailedTask). The notification absence-asserts pass (mcpkit already filters progress/message on tasks); the rename check passes (mcpkit already emits the new method name); the -32003 checks pass (mcpkit already returns the structured error).

Out of scope

• panyam/mcpkit requestState-removal PR — a follow-up on mcpkit, which will close the deliberate failing window opened by this PR.
• Re-engagement on modelcontextprotocol/conformance PR 262 — once this stack merges into feat/tasks-mrtr-extension, a comment on PR 262 noting the Final-merged alignment is the natural next step.

Test plan

• Pre-push lefthook (npm run lint:fix && git diff --exit-code + vitest run over 118 tests) green
• make testconf-tasks-v2 (mcpkit side) shows 8 of 9 scenarios pass; the failing one is the requestState-removal scenario, by design
• CI green