[v1.x] Scope experimental tasks to the session that created them (#2720)

docs/experimental/tasks-server.md

@@ -53,6 +53,29 @@ That's it. `enable_tasks()` automatically:
 - Registers handlers for `tasks/get`, `tasks/result`, `tasks/list`, `tasks/cancel`
 - Updates server capabilities
 
+## Task Visibility
+
+Task IDs generated by `run_task()` embed an opaque marker identifying the session that
+created the task, and the default handlers use it to restrict each session to its own
+tasks: `tasks/get`, `tasks/result`, and `tasks/cancel` respond with "task not found" for
+another session's task, and `tasks/list` returns only the requesting session's tasks. A
+client that reconnects gets a new session and can no longer reach tasks it created on the
+previous one.
+
+A task ID has no session marker when it was passed to `run_task()` explicitly, when the
+task was created directly through the `TaskStore`, or when the server runs in stateless
+mode (each request gets a fresh session, so tasks must remain reachable across requests).
+Such tasks are accessible to any requestor that presents the exact task ID, and are never
+included in `tasks/list` responses because the server cannot tell which session they
+belong to. Treat these task IDs as capabilities: generate them with enough entropy that
+they cannot be guessed, share them only with the intended recipient, and prefer short
+TTLs. Passing an explicit `task_id` to `run_task()` is deprecated for this reason.
+
+To scope tasks to something other than the session — for example a user identity from your
+authorization layer — register your own handlers with `@server.experimental.get_task()`,
+`@server.experimental.get_task_result()`, `@server.experimental.list_tasks()`, and
+`@server.experimental.cancel_task()` instead of relying on the defaults.
+
 ## Tool Declaration
 
 Tools declare task support via the `execution.taskSupport` field: