feat(L1): make deposit resource minimum base fee deploy-configurable

[dguenther]

Summary

• Add optional resourceConfigMinimumBaseFee to deploy config (default 1 gwei) and wire it into SystemConfig resource config initialization.
• Initialize ResourceMetering.prevBaseFee from the configured minimum instead of hardcoding 1 gwei, keeping portal metering aligned with the parent base-fee conversion floor.
• Regenerate snapshots/semver-lock.json for the updated OptimismPortal2 init bytecode.

Test plan

• just test --match-path test/deploy/ResourceConfigMinimumBaseFee.t.sol
• just test --match-path test/deploy/DeployConfig.t.sol
• just test --match-path test/L1/ResourceMetering.t.sol
• just test --match-path test/deploy/SystemDeploy.t.sol
• just semver-lock

L3 deploy config

Set "resourceConfigMinimumBaseFee": 10000000 to align the 0.01 gwei resource minimum with the portal conversion floor.

[robriks]

wow this touches some really involved mechanisms.

got pretty nerdsniped on how these gas configs are significant and am aligned that this the least invasive way to resolve the 100x overcharge for our use of this codebase as an L3.

long term, assuming the L3 goes to production, we might need to consider addressing this more invasively if gas conditions (on Base) are volatile and we expect to see high deposit volume.

that's because the 0.01gwei alignment between the minimum base fee and the conversion floor (enacted by this PR) can still be pushed out of balance if Base gas fees drop very low and deposit volume skyrockets.

accordingly, I think the long term solution would be to bound the burn itself so it's provably below the parent's per‑tx cap for the max deposit size. (Claude suggests to clamp gasCost or equivalently cap maximumBaseFee so _amount_max × maximumBaseFee / floor < 2^24). that way deposits would stay includable (ie don't revert) no matter what, with a downstream outcome that the fusaka limit becomes the canonical maximum fee to bridge to L3.

doing that would be pretty involved though since we'd definitely need to ascertain that bounding the burn doesn't create a cheaper‑spam or undercharge‑exploit surfaces. not worth the effort at this time but wanted to surface it as my recommendation if we get to that point

oh and also, Claude suggested that we bump @Custom:semver from 5.2.0 to 5.2.1 for this , I don't think we strictly need to in this PR but whenever we are "done" with the contract changes I think we should think about how to handle the semver so that it's clear our L3 versioning is distinct from canonical Base L2 versioning

[robriks]

could we reference Fusaka here in a doc comment? some chains don't implement the newer tx gas limit, and a future hard fork alters this value

[robriks]

could we expand this test or add another regression one asserting the issue itself? claude's suggestion:

    // 1 gwei default + parent base fee at the 0.01 gwei conversion floor => ~100x burn
    SystemDeploy.DeployOutput memory output = systemDeploy.deploy(_deployInput(uint32(1 gwei)));
    // ... resolve bridge/portal ...
    vm.fee(0.01 gwei);
    // ... measure gasUsed for the same depositETH call ...
    assertGe(gasUsed, BASE_TX_GAS_CAP); // proves the regression the fix prevents