document revert behavior where incorrect conduit key is provided

docs/SeaportDocumentation.md

@@ -51,7 +51,7 @@ Orders are fulfilled via one of four methods:
   - If the order has an ERC721 item, that item has an amount of `1`.
   - If the order has multiple consideration items and all consideration items other than the first consideration item have the same item type as the offered item, the offered item amount is not less than the sum of all consideration item amounts excluding the first consideration item amount.
 - Calling one of two "fulfill available" functions, `fulfillAvailableOrders` and `fulfillAvailableAdvancedOrders`, where a group of orders are supplied alongside a group of fulfillments specifying which offer items can be aggregated into distinct transfers and which consideration items can be accordingly aggregated, and where any orders that have been cancelled, have an invalid time, or have already been fully filled will be skipped without causing the rest of the available orders to revert. Additionally, any remaining orders will be skipped once `maximumFulfilled` available orders have been located. Similar to the standard fulfillment method, all offer items will be transferred from the respective offerer to the fulfiller, then all consideration items will be transferred from the fulfiller to the named recipient.
-- Calling one of two "match" functions, `matchOrders` and `matchAdvancedOrders`, where a group of explicit orders are supplied alongside a group of fulfillments specifying which offer items to apply to which consideration items (and with the "advanced" case operating in a similar fashion to the standard method, but supporting partial fills via supplied `numerator` and `denominator` fractional values as well as an optional `extraData` argument that will be supplied as part of a call to the `validateOrder` function when fulfilling restricted order types or to `generateOrder` and `ratifyOrder` as "context" on contract order types). Note that orders fulfilled in this manner do not have an explicit fulfiller; instead, Seaport will simply ensure coincidence of wants across each order.
+- Calling one of two "match" functions, `matchOrders` and `matchAdvancedOrders`, where a group of explicit orders are supplied alongside a group of fulfillments specifying which offer items to apply to which consideration items (and with the "advanced" case operating in a similar fashion to the standard method, but supporting partial fills via supplied `numerator` and `denominator` fractional values as well as an optional `extraData` argument that will be supplied as part of a call to the `validateOrder` function when fulfilling restricted order types or to `generateOrder` and `ratifyOrder` as "context" on contract order types). Note that orders fulfilled in this manner do not have an explicit fulfiller; instead, Seaport will simply ensure coincidence of wants across each order.  Note also that contract orders do not enforce usage of a specific conduit, but a contract offerer can require the usage of a specific conduit by setting allowances or approval on tokens for specific conduits.  If a fulfiller does not supply the correct conduit key, the call will revert.  There's currently no endpoint for finding which conduit a given contract offerer prefers.
 
 While the standard method can technically be used for fulfilling any order, it suffers from key efficiency limitations in certain scenarios: