fix(pattern): correct cross-chain atomicity claims in ERC-7573 cards

[oskarth]

The private PvP card claimed "both legs settle or both revert, without relying on time-locks for safety." Its own recipe finalised the paying leg first (step 3) and then said both escrows revert on failure (step 6). A settled payment can't revert. Step 2 also had each escrow wait on the other leg, which can't release either.

What changes

• Private PvP via ERC-7573: the recipe now follows the shape ERC-7573 specifies. One leg is locked, the other pays through the decryption contract, and the oracle's key releases or returns the locked leg ("for a two-party DvP with two tokens only one token requires locking", EIP-7573). The guarantee is now conditional settlement with its assumptions named: verified key setup, an honest and available oracle, and key delivery. The card also says ERC-7573 has no timeout; it replaces HTLC time-locks with trust in the oracle.
• Atomic DvP via ERC-7573: drops the timeout reclaim, which ERC-7573 doesn't define and which can fire after the buyer has paid. Step 1 now names a target settlement time, not a guaranteed unwind.
• Permissioned Ledger Interoperability: a malicious two-phase-commit coordinator can split the outcome, not only stall it (Zhao; Canton's docs treat the mediator as trusted). The partition line now says two-phase commit blocks rather than breaks.

Other sources: the authors' paper (arXiv 2311.05966), Zamyatin et al. on why cross-chain atomicity needs a trusted party or synchrony, and Gray and Lamport.

Checks

• validate-patterns.js and check-terminology.js pass in strict mode.
• The PvP card is 905 words, over the 800-word soft limit (warning only; the DvP card was already over it).

[rymnc]

lgtm, some comments inline