feat(tasks/get): add include_result + result fields for typed completion-payload retrieval (3.1)

[bokelley]

Summary

Closes #3123. Adds the schema-level fix: a typed include_result request flag and a typed result response field on tasks/get, so buyers polling a submitted task can retrieve the terminal payload (e.g. media_buy_id, packages from a completed create_media_buy) without depending on additionalProperties undocumented behavior.

This is the 3.1 follow-up to #3127 (3.0.1 docs patch). #3127 stops the 3.0 docs from describing a parameter that doesn't exist; this PR makes the parameter exist for 3.1.

Changes

static/schemas/source/core/tasks-get-request.json — adds include_result (boolean, default false). Sellers MUST honor the flag when the task is in a terminal status; for non-terminal statuses the flag has no effect. New example in the schema's examples array.

static/schemas/source/core/tasks-get-response.json — adds result (object, additionalProperties: true) populated only when status: completed and include_result: true was sent. Shape matches the original task response payload for the task's task_type. For failed/canceled, sellers continue to use the existing error field; result is for the success terminal only.

docs/building/implementation/task-lifecycle.mdx — adds an explanatory paragraph to the polling section. The four other call sites previously stripped by patch #3127 (async-operations.mdx ×2, error-handling.mdx, orchestrator-design.mdx) are intentionally left for the rebase post-#3127-merge to keep this PR focused on the schema change.

Why a typed result instead of flat top-level merge

AdCP's flat-structure principle ("task fields at top level") applies to the original task response, where the response carries one task. tasks/get is a meta-call about an arbitrary task whose task_type is variable — flat-merging the terminal payload at top level would force progress/error/result fields to share namespace with task-specific fields and would couple the tasks/get response shape to the union of every task's response shape. Naming the projection result makes the typed retrieval explicit, parallels MCP's tasks/result envelope, and matches what existing SDK code at adcp-client already attempts to read (status.result).

Versioning

Per docs/reference/versioning.mdx:93:

Add a new error code or new optional field to a request/response schema | Minor

And per docs/reference/versioning.mdx:121:

Patches never change schema — no new fields, no renamed fields, no new enum values.

This PR is minor and targets the 3.1 milestone (late June 2026). The 3.0.1 patch is #3127.

Forward compatibility

3.0 sellers ignore unknown request fields per additionalProperties: true, so a 3.1 buyer sending include_result: true to a 3.0 seller gets the 3.0 behavior (no result field on the response) — no error, no break. Buyers that need 3.1 semantics check adcp.major_versions advertised by the seller.

Cross-repo

Unblocks adcp-client#967 (SDK polling-cycle hardening) and the adcp-client-python equivalent. The SDK's pollTaskCompletion TaskResult.data extraction will read response.result when present, falling back to response itself for 3.0 sellers that splat task fields via additionalProperties.

Test plan

• npm run build:schemas produces a valid bundled tasks-get-request.json with include_result and tasks-get-response.json with result
• npm run test:unit and npm run typecheck pass via pre-commit hook
• Reviewer: confirm the result shape semantics ("matches the original task response payload for the task's task_type") read correctly against working-group expectations
• Reviewer: confirm the failed/canceled exclusion ("for failed/canceled use error instead") matches working-group intent
• Once docs(tasks/get): remove non-existent include_result flag from polling examples #3127 lands, rebase this PR and re-introduce include_result: true to the four polling examples that were stripped by the patch

🤖 Generated with Claude Code

[bokelley]

Closing in favor of #3126, which does the same schema-additive work but uses a better-typed shape — result references /schemas/core/async-response-data.json (the existing anyOf union maintained for webhook payloads) instead of my hand-rolled type: object. That keeps the polled tasks/get result and the webhook result typed identically and avoids duplicate shape maintenance.

The 3.0.1 docs patch #3127 is unaffected — they form the same two-PR stack (patch + minor) we discussed on #3123.