feat: Securitize collateral vault V2 with hardened share-movement authorization

[kasperpawlowski]

Summary

Introduces ERC4626EVCCollateralSecuritizeV2 and ERC4626EVCCollateralSecuritizeFactoryV2, superseding the v1 Securitize collateral vault/factory with two authorization fixes and versioning the factory so existing deployments are untouched.

The v1 vault and factory remain immutable on-chain and are still referenced by the existing securitizeFactory address-book key. New deployments use a new securitizeFactoryV2 key; existing per-chain address books need no edits (a missing key deserializes to address(0)).

Fixes

Both harden the vault's "value only moves within an EVC account family, except a genuine liquidation" invariant. They are motivated by bug-bounty findings Cantina #604 and Cantina #592.

Cross-frame control-collateral authorization (Cantina #604)

_requireTransferAuthorized now binds the transfer from to the account authenticated for the current EVC frame (from == _msgSender()).

Previously the cross-owner branch checked only that a controlCollateral frame was in progress and that getControllers(from)[0] was perspective-verified — it never required from to be the account that opened the frame. An allowance holder could open a controlCollateral frame for their own account (with a trivial self-installed controller) and forward transferFrom(victim, attacker, amount), borrowing an unrelated victim's genuine verified controller to move the victim's shares cross-owner. The EVK liquidation path uses transfer (where from == _msgSender() by construction) and is unaffected.

Withdraw/redeem receiver binding (Cantina #592)

The V2 vault overrides the public withdraw and redeem (mirroring the existing deposit/mint overrides) to require the underlying payout receiver to share the share owner's EVC account family (isCommonOwner(owner, receiver); otherwise NotAuthorized).

Previously withdraw/redeem inherited generic ERC-4626 receiver semantics, so an owner could route the underlying to an unrelated (still eligible) account. Because the vault is a registered platform wallet, that substitution removes the original holder from the source-side issuance hold-up evaluation. Liquidation and governor seizure move shares (not the underlying) to the recipient, which then redeems its own shares to its own family, so those flows are unaffected (verified by tests).

Deployment scripts

• ScriptUtils PeripheryAddresses keeps securitizeFactory (v1, read-only) and adds securitizeFactoryV2 (struct + serialize + deserialize).
• 50_CoreAndPeriphery deploys the V2 factory under the securitizeFactoryV2 key behind a deploySecuritizeFactoryV2 flag; the v1 factory is never redeployed.
• interactiveDeployment.sh keeps the v1 loader and adds the v2 loader/prompt/compile/input; verifyContracts.sh verifies …FactoryV2.

Test plan

• forge test --match-path test/Vault/ERC4626EVCCollateralSecuritize.t.sol — 13/13 pass
• New regression tests: cross-frame steal reverts; withdraw/redeem to an unrelated receiver reverts
• Liquidation/seizure unaffected: a liquidation succeeds and the liquidator redeems its seized shares to its own family (but not to an unrelated one); governor seize succeeds and the recipient redeems to its own family
• Existing testCollateralSecuritizeVault_liquidate and ..._freeze remain green (no regression to legitimate liquidation or freeze paths)

Notes

• The fixes apply to future V2 deployments; the already-deployed v1 vaults are immutable and out of scope for a code change.
• Only the factory and vault are versioned to V2; the ancillary IDSToken / compliance interfaces are unchanged.