[Server] SEP-2663 Tasks: Handlers return task handles; the application advances the task

Execution model for SEP-2663 for the 2026-07-28 release. Tracked by umbrella #335.

Decision

The SDK owns storage and the tasks/* surface; advancing a task is the application's job. PHP has no in-process background executor to build on, and picking a queue or process model on the user's behalf would be the wrong call for a framework-agnostic SDK.

Scope

• Any tool, prompt or resource handler may return a CreateTaskResult (via TaskContext::create()) instead of its usual result; the core handlers pass any ResultInterface a handler returns through untouched, so no core code knows about tasks.
• What happens next is application code: enqueue something a worker picks up, and have the worker call $store->save($task->with(...)) as it progresses. TaskContext::getStore() gives a handler the store for a task it did not create in this request.
• TaskInputHandlerInterface is the hook for what an answer to a parked (input_required) task means; TasksUpdateHandler delegates inputResponses to it.
• No #[McpTool] task-eligibility marker and no early-return path in ReferenceHandler: whether to create a task is the handler's decision, made per request.

Inizia leggendo TaskContext::create(), TaskContext::getStore(), TaskInputHandlerInterface e TasksUpdateHandler. Segui il modo in cui gli handler restituiscono valori ResultInterface e il modo in cui lo store salva l’avanzamento delle task; il lavoro è completato quando i risultati delle task passano attraverso il sistema, l’input delle task parcheggiate viene delegato correttamente e il codice dell’applicazione può far avanzare le task senza logica specifica delle task nel core.