Update base-org/contracts dependency

[mdehoog]

Description

We did a big cleanup of the *MultisigBuilder contracts in base-org/contracts#97.

This PR bumps the base-org/contracts dependency to pick up these changes, and makes all the required updates for the scripts.

Tests

I tested one of the tasks before and after this change to ensure that the same data-to-sign was produced, as well as the same output / assertions.

[mdehoog]

This can be simplified with base-org/contracts#103... converting to draft until this is merged

[mds1]

This looks great, and the upstream base-org/contracts change are really nice. Thank you for this!

I tested one of the tasks before and after this change to ensure that the same data-to-sign was produced, as well as the same output / assertions.

Before merging, @Ethnical can you:

• Double check that tasks generate the same data to sign before and after this change
• Also verify the presigned pauses (https://github.com/ethereum-optimism/superchain-ops/pull/356/files#r1825095331)
• Review Refactor MultisigBuilder and NestedMultisigBuilder base-org/contracts#97, just to ensure we're familiar with the changes so we know how they might help us with upcoming superchain-ops improvements

I don't expect any issues with any of the above, but just want to be sure before we merge

[mds1]

I've confirmed all the above tasks, so will merge

@mdehoog One thing I noticed is that the state overrides in the nested case seem to be different—we no longer update the Safe owners to be a single owner of the Multicall3 contract. Was this intentional, and if so what is the new approach for nested overrides?

[mdehoog]

thanks for the review @mds1!

I didn't intentionally update the simulation overrides, but I believe the owner=multicall override is still present?
https://github.com/base-org/contracts/blob/12afb9f603bfe20a59dd772ae9bb9a8e68e14d45/script/universal/NestedMultisigBuilder.sol#L220

[mds1]

I noticed differently tenderly URLs when comparing the 018-granite-upgrade task on main vs. this branch: Here is a diff, the right side is the new URL: https://difff.jp/en/eyse3.html

And corresponding screenshot of the tenderly UI when loading that URL

The issue here might be related to the fact that the task is already executed and now effective has a no-op state diff, so I did not investigate this much