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

Beginne mit dem Lesen von TaskContext::create(), TaskContext::getStore(), TaskInputHandlerInterface und TasksUpdateHandler. Verfolge, wie Handler ResultInterface-Werte zurückgeben und wie der Store den Aufgabenfortschritt speichert; abgeschlossen ist die Aufgabe, wenn Aufgabenergebnisse weitergereicht werden, die Eingabe für geparkte Aufgaben korrekt delegiert wird und Anwendungscode Aufgaben ohne aufgabenspezifische Logik im Core voranbringen kann.