fix(SEP-2322): Break resultType extension requirement into two clauses

Co-authored-by: Caitie McCaffrey <caitiem20@github.com>

Author: LucaButBoring

docs/specification/draft/basic/index.mdx

@@ -79,7 +79,8 @@ can use to determine how to parse and handle the `result` object.
 
 - A `resultType` of `"complete"` indicates the request completed successfully and the result contains the final content.
 - A `resultType` of `"input_required"` indicates the request is incomplete and more information is needed to process the request. The result contains an `InputRequiredResult` object with additional information needed.
-- A `resultType` of any value unrecognized by the client **MUST** be considered invalid. This field is open to extension.
+- Extensions MAY add additional `ResultType` values. The set of supported `ResultTypes` MUST be created from the set defined in the core protocol and include any additional values of supported extensions that are advertised via capabilities.
+-A `resultType` of any value unrecognized by the client **MUST** be considered invalid.
 - For backward compatibility with servers implementing earlier protocol versions, which do not include `resultType`, clients **MUST** treat an absent `resultType` as `"complete"`.
 
 #### Error Responses

seps/2322-MRTR.md

@@ -320,7 +320,13 @@ export interface InputResponseRequestParams extends RequestParams {
 }
 ```
 
-Since this change creates a polymorphic response for method calls like 'tools/call', we are introducing a new field to `Result` which indicate the `ResultType`. The client should parse this field to determine the type of the Result contained in the message, treating unrecognized values as invalid protocol responses. The `ResultType` is open for extensions to introduce additional values. If this field is not provided the Client should assume a `ResultType` of "complete" for backwards compatibility. The schema change will look like this:
+Since this change creates a polymorphic response for method calls like 'tools/call', we are introducing a new field to `Result` which indicate the `ResultType`. The client should parse this field to determine the type of the Result contained in the message. If this field is not provided the Client should assume a `ResultType` of "complete" for backwards compatibility. If this field is not provided the Client should assume a `ResultType` of "complete" for backwards compatibility. 
+
+Extensions MAY add additional `ResultType` values. The set of supported `ResultTypes` MUST be created from the set defined in the core protocol and include any additional values of supported extensions that are advertised via capabilities.
+
+The Client SHOULD treat unrecognized values as invalid protocol responses. 
+
+The schema change will look like this:
 
 ```typescript
 /**