Update progress spec to reflect task semantics

Author: LucaButBoring

docs/specification/draft/basic/utilities/progress.mdx

@@ -68,6 +68,10 @@ The receiver **MAY** then send progress notifications containing:
    - Send notifications at whatever frequency they deem appropriate
    - Omit the total value if unknown
 
+3. For task-augmented requests, the `progressToken` provided in the original request **MUST** continue to be used for progress notifications throughout the task's lifetime, even after the `CreateTaskResult` has been returned. The progress token remains valid and associated with the task until the task reaches a terminal status.
+   - Progress notifications for tasks **MUST** use the same `progressToken` that was provided in the initial task-augmented request
+   - Progress notifications for tasks **MUST** stop after the task reaches a terminal status (`completed`, `failed`, or `cancelled`)
+
 ```mermaid
 sequenceDiagram
     participant Sender

docs/specification/draft/basic/utilities/tasks.mdx

@@ -417,6 +417,10 @@ stateDiagram-v2
 1. For example, an elicitation that a task-augmented tool call depends on **MUST** share the same related task ID with that tool call's task.
 1. For the `tasks/get`, `tasks/list`, `tasks/result`, and `tasks/delete` operations, the `taskId` parameter in the request **MUST** be used as the source of truth for identifying the target task. Requestors **SHOULD NOT** include `modelcontextprotocol.io/related-task` metadata in these requests, and receivers **MUST** ignore such metadata if present in favor of the RPC method parameter.
 
+### Task Progress Notifications
+
+Task-augmented requests support progress notifications as defined in the progress notification specification. The `progressToken` provided in the initial request remains valid throughout the task's lifetime.
+
 ### Task Cancellation
 
 1. Requestors **MAY** send `notifications/cancelled` at any time during task execution.