[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.

Commencez par lire TaskContext::create(), TaskContext::getStore(), TaskInputHandlerInterface et TasksUpdateHandler. Suivez la manière dont les handlers renvoient des valeurs ResultInterface et dont le store enregistre la progression des tâches ; le travail est terminé lorsque les résultats des tâches sont transmis, que l’entrée des tâches mises en attente est correctement déléguée et que le code de l’application peut faire avancer les tâches sans logique spécifique aux tâches dans le core.