Add client conformance for SEP-2663 task results

[brixton-guns]

Summary

• add tasks-client-create-handling, where the harness returns a server-directed CreateTaskResult from tools/call and requires the client to retrieve it with tasks/get
• register the scenario in the extensions suite by deriving membership from source.extensionId, and allow extension scenarios to declare the core protocol version they layer on
• update the TypeScript everything-client fixture to negotiate the Tasks extension and drive the polling flow
• add positive and deliberately broken no-poll coverage
• integrate the Tasks extension flow with the suite's per-version wire-schema validation

Why

The server suite already covers SEP-2663, but the client suite could not observe the client requirement to handle either a standard result or CreateTaskResult. This implements the first client scenario proposed in #374.

The scenario is black-box: it proves that the client recognizes the task envelope and follows the returned handle with tasks/get. It does not claim to observe application-level use of the completed result.

Alignment with current main

Rebased onto 49103de, incorporating the 11 upstream commits added since the original PR base.

• layer the Tasks extension on DRAFT_PROTOCOL_VERSION (2026-07-28)
• use the final MISSING_REQUIRED_CLIENT_CAPABILITY code, -32021
• record requests and responses from the custom Tasks mock in the new wire validator
• validate extension-defined CreateTaskResult as a base draft Result envelope, since Tasks v2 types intentionally live outside the core draft schema
• keep wire-schema-valid green for both the conformant and deliberately broken client paths

Validation

• npm run check
• npm run build
• npm test — 488 tests passed
• targeted Tasks, runner, and wire-schema tests — 31 tests passed
• end-to-end conformant client run on Node 22.23.1 — 2/2 checks passed, including wire-schema-valid
• end-to-end no-poll client run — fails only sep-2663-client-handles-polymorphic-result with the expected diagnostic; wire-schema-valid passes

Addresses #374.

[brixton-guns]

Hi @pcarleton @LucaButBoring — gentle ping on this one. This implements the first client-side SEP-2663 scenario from #374. The PR is ready for review, but it hasn’t had a review yet and the required check is still waiting. When you have a chance, could one of you take a look and help get CI moving? Happy to address any feedback. Thanks!

[LucaButBoring]

I don't have permission to run the check or approve the PR but taking a look at the tests now

[LucaButBoring]

We need to assert this on all task-related operations, not just the initial tool call.

[brixton-guns]

Thanks — that’s a real gap.

I checked this against src/seps/sep-2663.yaml: the per-request capability requirement is already explicit there, including the “regardless of prior declarations” language, so I’ll enforce it on tasks/get as well as the task-producing tools/call in this scenario.

One modelling question before I push. Since the requirement is phrased as a server obligation and the harness plays the server here, would you prefer a distinct client-side check id — e.g. sep-2663-client-declares-capability-on-tasks-methods, scoped to tasks/get in this scenario, with the remaining task methods covered by the other #374 scenarios — or should it remain a separate failure reason under sep-2663-client-handles-polymorphic-result?

Either way, I’ll track the tasks/get attempt separately from whether it declared the extension and add a negative-control client for that case, so a client that does poll but omits the capability won’t incorrectly report “did not retrieve it with tasks/get”.

I’d rather not add or change traceability ids on my own initiative. If you’d rather not decide that now, I’ll default to keeping the distinct failure reason under the existing id, leaving the traceability manifest untouched; it can always be split into its own check later.

[LucaButBoring]

Mostly looks good, left one comment for a requested change