feat: use safe block finality for L2 syncers

[arnaubennassar]

🔄 Changes Summary

• Switches the default block finality of the L2 syncers from LatestBlock to SafeBlock, so they stop indexing L2 blocks that may still be reorged. Requested by the maintainer.

⚠️ Breaking Changes

• 🛠️ Config: [BridgeL2Sync] and [L2GERSync] default BlockFinality changes from LatestBlock to SafeBlock (deployments that want the old behaviour can still set it explicitly). [ClaimL2Sync] needs no edit — it inherits the new value through its existing {{BridgeL2Sync.BlockFinality}} reference.

📋 Config Updates

• 🧾 Diff/Config snippet:

  [BridgeL2Sync]
  - BlockFinality = "LatestBlock"
  + BlockFinality = "SafeBlock"
  
  [L2GERSync]
  - BlockFinality = "LatestBlock"
  + BlockFinality = "SafeBlock"

✅ Testing

• 🖱️ Manual: go build -buildvcs=false ./...; go test -count=1 ./config/...; gofmt -l config/ (clean); golangci-lint run ./config/... (0 issues).

📝 Notes

• Follow-up needed: docs/bridge_service.md (public-config example responses) and test/e2e/envs/anvil-2chains/config/002/aggkit-config.toml still show/pin the old LatestBlock value explicitly; intentionally left untouched in this PR and will need a touch-up.

[arnaubennassar]

Pushed a CI fix (4392903): the multi-chains CDK Erigon e2e job was failing because [BridgeL2Sync] in the kurtosis e2e template (test/e2e/kurtosis/aggkit-config.template.toml) doesn't pin BlockFinality, so it picked up the new SafeBlock default — and the kurtosis cdk-erigon L2 nodes never advance the safe block tag, so the L2 bridge syncer indexed zero blocks and get_bridge timed out on every L2-origin deposit. The fix pins BlockFinality = "LatestBlock" for cdk-erigon chains only (same sequencer_type branching the template already uses); OP / op-succinct chains keep the new SafeBlock default, and their e2e jobs passed with it, so the new default stays covered. The two anvil-2chains Go E2E failures were transient proxy.golang.org download errors (stream error: INTERNAL_ERROR) during module fetch — tests never ran; they're re-running now. govulncheck is pre-existing: develop at this PR's base (f7c15f5) fails the same check with the same 5 x/net@v0.58.0 vulns (GO-2026-6617/6612/6611/6610/6603, fixed in x/net v0.60.0) — worth a separate bump on develop.