fix(L1): seed imported schedule protocol version

[jackchuma]

What changed? Why?

• Extend ProtocolVersions.initialize to set the minimum packed protocol version atomically with an imported schedule and reject non-zero activation timestamps when that version is zero.
• Plumb protocolVersionsInitialMinimumVersion through the standard and multiproof deployment paths, retaining the config parser's packed-version bound check.
• Preflight the imported schedule/version invariant before SystemDeploy sends any broadcast transaction, preventing invalid configuration from stranding a partially deployed deterministic system.
• Add regression and deployment coverage, document the new config field, and refresh the ABI and semver snapshots.

This keeps imported activation schedules immediately consumable by nodes, which reject positive activation timestamps paired with protocol version zero.

Notes to reviewers

• Empty and zero-only initial schedules may still leave the minimum protocol version at zero.
• Non-zero initial versions retain the existing 128-bit packed-semver bound.
• minimumProtocolVersion remains outside the scheduleId commitment.
• The initializer remains the contract-level trust boundary. SystemDeploy mirrors the invariant only as a preflight because script broadcasts are separate transactions and a later revert cannot roll back earlier broadcasts.
• The deployment integration test verifies the resulting schedule and minimum version; there is no duplicate post-deployment readback in the script.

How has it been tested?

• just test
• just test --match-path test/deploy/SystemDeploy.t.sol
• just test --match-path test/L1/ProtocolVersions.t.sol
• just build-no-tests
• just test --match-test test_cannotReinitialize_succeeds
• just snapshots
• forge fmt --check
• just lint-forge-tests-check-no-build
• just validate-spacers-no-build

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/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]

Should we also validate that non-zero timestamps are ordered here, since an unordered schedule passes this preflight and only reverts in initialize after earlier deployment transactions have been broadcast?

[leopoldjoy]

Should we mirror the imported schedule validation in _preflight() before startBroadcast(), otherwise an invalid schedule/minimum-version pair would revert only after the infrastructure and TEE transactions have been sent?