Seaport 1.6 and Immutable Signed Zone V3

[lfportal]

Seaport 1.6 and Immutable Signed Zone V3

• Adds Seaport 1.6 contract (Immutable fork with zone restrictions)
• Adds Immutable Signed Zone V3, notable differences compared to V2:
  • Compatibility with Seaport 1.6's updated Zone interface (addition of authorizeOrder function)
  • Adds support for SIP-7 substandards 1, 7 and 8

---

[!NOTE] Adds Seaport 1.6 (with zone restrictions) and a new Immutable Signed Zone V3 (SIP‑7 substandards + authorizeOrder), with extensive tests and CI/tooling updates (Foundry, Hardhat, publish).

• Smart contracts:
  • Add contracts/trading/seaport16/ImmutableSeaport.sol (Seaport 1.6 fork) enforcing restricted order types and an allowedZones allowlist across all fulfillment/match paths.
  • Add contracts/trading/seaport16/zones/immutable-signed-zone/v3/ImmutableSignedZoneV3.sol implementing SIP-7 (substandards 1,3,4,6,7,8), SIP-6 extraData, and Seaport 1.6 authorizeOrder/validateOrder, with access control and signer management.
  • Include conduit controller shim and validator helpers for Seaport 1.6.
• Tests:
  • Introduce comprehensive Seaport 1.6 and Signed Zone V3 unit/integration tests, harnesses, helpers, and README test plans.
• Tooling/CI:
  • Update workflows to install Foundry/forge, compile/test with Foundry/Hardhat, and perform NPM pack/provenance (plus dry-run in CI).
  • Hardhat config adds @nomicfoundation/hardhat-foundry, compiler 0.8.24 (Cancun), and per-file overrides; add Foundry lock/remappings.
  • Dependencies/submodules updated: add seaport-16, seaport-core-16, seaport-types-16, creator-token-standards; bump Hardhat; update DEPS and .gitignore.

^{Written by Cursor Bugbot for commit 8e7b8ae83cdbd5e88a7152d5bc355e2f64ea69c2. This will update automatically on new commits. Configure here.}

[lfportal]

Note for discussion: The authorizeOrder and validateOrder functions are assumed to be called together in that order which Seaport will guarantee. The functions are not view or pure (to support SIP-7 substandards 7 and 8 creator token standard callbacks), so they may change state. The functions are also currently not restricted to any particular caller - this was fine for previous versions of this zone which designated validateOrder as view function. Given the assumptions, the functions should be caller restricted to preserve the semantics of the creator token standard. What options do we have to apply restrictions?

Edit: Added caller (msg.sender) restriction to authorizeOrder and validateOrder functions. The Seaport address is obtained via the zone constructor for simplicity.