Clarify that requestors may continue polling after calling tasks/result

Author: LucaButBoring

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

@@ -185,7 +185,7 @@ This guidance is non-binding and is provisional logic intended to account for th
 Requestors poll for task completion by sending [`tasks/get`](/specification/draft/schema#tasks%2Fget) requests.
 Requestors **SHOULD** respect the `pollInterval` provided in responses when determining polling frequency.
 
-Requestors **SHOULD** continue polling until the task reaches a terminal status (`completed`, `failed`, or `cancelled`), or until encountering the [`input_required`](#input-required-status) status.
+Requestors **SHOULD** continue polling until the task reaches a terminal status (`completed`, `failed`, or `cancelled`), or until encountering the [`input_required`](#input-required-status) status. Note that invoking `tasks/result` does not imply that the requestor needs to stop polling - requestors **SHOULD** continue polling the task status via `tasks/get` if they are not actively waiting for `tasks/result` to complete.
 
 **Request:**
 
@@ -223,6 +223,8 @@ After a task completes the operation result is retrieved via [`tasks/result`](/s
 
 To retrieve the result of a completed task, requestors can send a `tasks/result` request:
 
+While `tasks/result` blocks until the task reaches a terminal status, requestors can continue polling via `tasks/get` in parallel if they are not actively blocked waiting for the result. This allows requestors to monitor status changes or display progress updates while the task executes, even after invoking `tasks/result`.
+
 **Request:**
 
 ```json