SEP-2663: Remove mentions of tasks from MRTR

Author: LucaButBoring

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

@@ -247,47 +247,6 @@ what is directly present in the retry request.
 1. The JSON-RPC `id` **MUST** be different between the initial request and the retry, as they are independent requests.
 1. Both the `inputRequests` and `requestState` fields affect only the client's retry of the original request. They **MUST NOT** be used for any other request that the client may be sending in parallel.
 
-### Tasks Workflow
-
-For long-running operations that require server-side state, the persistent workflow leverages [Tasks](/seps/2663-tasks-extension). The `input_required` task status indicates that additional information is needed.
-
-```mermaid
-sequenceDiagram
-    participant U as User
-    participant C as Client
-    participant S as Server
-    C->>S: tools/call (id: 1, task config)
-    S-->>C: Result (id: 1, taskId, status: working)
-
-    note over C,S: Client polls for task status while server processes request
-
-    note over S: Server needs more info via Elicitation <br/> sets state to input_required
-    C->>S: tasks/get (id: 2, taskId)
-    S-->>C: Result (id: 2, status: input_required)
-
-    C->>U: Prompts user for input
-    U-->>C: Provides responses
-
-    C->>S: tasks/update (id: 3, taskId, ElicitResult)
-    S-->>C: Result (id: 3, acknowledged)
-
-    note over C,S: Processing resumes, Client polls
-    C->>S: tasks/get (id: 4, taskId)
-    S-->>C: Result (id: 4, status: completed, final content)
-```
-
-#### Server Requirements (Tasks)
-
-1. Servers **MAY** respond to `tasks/get` by indicating that the task is in status `input_required`.
-1. Servers **MUST** include an `inputRequests` field in the `tasks/get` response when the task is in status `input_required`.
-1. `inputRequests` keys are server assigned identifiers and **MUST** be unique within the scope of a `Task`.
-1. Servers **MAY** include a `requestState` field in the `tasks/get` response when the task is in status `input_required`.
-
-#### Client Requirements (Tasks)
-
-1. When `tasks/get` shows status `input_required`, clients **SHOULD** construct the results of those requests and call [`tasks/update`](seps/2663-tasks-extension#task-input-requests) with the `inputResponses` & `requestState` (if present).
-1. Clients **MAY** choose not to fulfill the input requests, in which case they **MAY** cancel the task.
-
 ### Error Handling
 
 Servers **SHOULD** validate that the data provided by the client is a valid `InputResponses` object and that the information inside can be correctly parsed.