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

Start by reading TaskContext::create(), TaskContext::getStore(), TaskInputHandlerInterface, and TasksUpdateHandler. Trace how handlers return ResultInterface values and how the store saves task progress; done means task results pass through, parked-task input delegates correctly, and application code can advance tasks without core task-specific logic.