Add MultisigScriptDeposit extension for L1→L2 deposits

[leopoldjoy]

This PR adds MultisigScriptDeposit, an extension of MultisigScript that simplifies L1→L2 deposit transactions.

More specifically:

• Task writers define L2 calls via _buildL2Calls() instead of manually wrapping in depositTransaction
• Automatically wraps L2 calls in OptimismPortal.depositTransaction targeting CBMulticall on L2
• Supports ETH bridging (sums values from L2 calls)

[cb-heimdall]

✅ Heimdall Review Status

Requirement	Status	More Info
Reviews	✅ 1/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[leopoldjoy]

Since PR #170 makes some changes to the MultisigScript, we should hold off on merging this PR until that one is complete. I will make any necessary modifications to this one.

[jackchuma]

I'm no longer convinced this is the right way to do things. If the calculated gas limit changes between sign, approve and run calls, the signatures will no longer be valid. I think moving this estimation into the signer tool during the validation file generation might make more sense to guarantee that the value does not change. The validation file could get an optional l2GasLimit field where, if set, the signer tool knows to add that as an env var. From the context of this script, expecting the env var to be set would work in that case

[leopoldjoy]

I'm no longer convinced this is the right way to do things. If the calculated gas limit changes between sign, approve and run calls, the signatures will no longer be valid. I think moving this estimation into the signer tool during the validation file generation might make more sense to guarantee that the value does not change. The validation file could get an optional l2GasLimit field where, if set, the signer tool knows to add that as an env var. From the context of this script, expecting the env var to be set would work in that case

Thanks, good call with this, was an implementation oversight on my part! I've switched back to the env var approach now.