feat: add EIP-1271 bulk order limitation

docs/SeaportDocumentation.md

@@ -589,3 +589,4 @@ In other words, if `_isValidBulkOrderSize` returns true, Seaport will call `_com
 - As orders filled by the "fulfill available" method will only be skipped if those orders have been cancelled, fully filled, or are inactive, fulfillments may still be attempted on unfulfillable orders (examples include revoked approvals or insufficient balances). This scenario (as well as issues with order formatting) will result in the full batch failing. One remediation to this failure condition is to perform additional checks from an executing zone or wrapper contract when constructing the call and filtering orders based on those checks.
 - As order parameters must be supplied upon cancellation, orders that were meant to remain private (e.g. were not published publicly) will be made visible upon cancellation. While these orders would not be _fulfillable_ without a corresponding signature, cancellation of private orders without broadcasting intent currently requires the offerer (or the zone, if the order type is restricted and the zone supports it) to increment the counter.
 - As order fulfillment attempts may become public before being included in a block, there is a risk of those orders being front-run. This risk is magnified in cases where offered items contain ascending amounts or consideration items contain descending amounts, as there is added incentive to leave the order unfulfilled until another interested fulfiller attempts to fulfill the order in question. Remediation efforts include utilization of a private mempool (e.g. flashbots) and/or restricted orders where the respective zone enforces a commit-reveal scheme.
+- As bulk order signatures expect an ECDSA signature with a length of 64 or 65 bytes, any EIP-1271 smart account signature longer than that will break the derivation of `bulkOrderHash`, causing the subsequent signature validation in `_assertValidSignature` to fail. Fall back to single order creation in such cases.