op-batcher: use one BatchAuthenticator reader, bound and code-checked once at startup

[shenkeyao]

Closes #503.

This PR:

• Follows up on Espresso 3b: TEE batcher (re-hosted) #459 (comment) to add batchAuthenticatorReader and tests.

Key places to review:

• op-batcher/batcher/batch_authenticator.go
• op-batcher/batcher/batch_authenticator_test.go

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1217525743187730

[palango]

No functional bugs, I'd approve once the comment and test bits below are in. Build, go vet and go test -race ./op-batcher/batcher/ pass on 51bb935.

Reading SystemConfig from the BatchAuthenticator is right, despite #503: authenticateBatchInfo checks its own stored systemConfig.batcherHash() (BatchAuthenticator.sol:174), and there's no setter, so caching it is fine too.

1. The cost comment (espresso_active.go:22-26) is off. The gate runs before every publishTxToL1 call, including the trailing io.EOF one (driver.go:889), and a wrong mode costs 1 call while the first fallback check costs 3 plus a CodeAt. "At most two in steady state" would be accurate.
2. batcherKeyUnauthorized is only cleared on success (espresso_active.go:69). Flip the switch away and back with the key still wrong and there's no fresh Warn, and the eventual Info reports a duration covering the other mode. Clear it in the mode-mismatch branch too.
3. shouldSkipPublishForActiveSeq is changed here but still untested: flip either return true (espresso_driver.go:309, :320) and the package stays green.
4. The wrong-mode rows in TestIsBatcherActive (batch_authenticator_test.go:263-264) would fail the identity check anyway, so only wantCalls catches a missing mode check. Add a row where one key holds both roles.
5. Nothing asserts the throttling, and four subtests print unchecked WARNs. testlog.CaptureLogger would fix both.
6. Error paths in isBatcherActive, resolveTEEVerifierAddress and registerBatcher aren't covered.

ensureDeployed/haveCode can go. The bindings already call CodeAt when an eth_call returns empty and give bind.ErrNoCode (op-geth accounts/abi/bind/v2/base.go:238-249), so the latched probe adds nothing for reads. registerBatcher sends a tx, so it should keep a plain CodeAt. systemConfigCaller can then use readContract instead of its own timeout.

Nits: an uninitialized proxy reverts rather than returning zero, and the deploy scripts initialize atomically, so the rationale at batch_authenticator.go:32-37 doesn't hold and the zero checks are unreachable (keep or drop, your call). service.go:316 overstates it: auth txs to 0x0 succeed as no-ops, so it's wasted gas, not failed batches. "serialized today" (:44) is a temporal comment.

[palango]

Two follow-ups, not for this PR:

1. The three tx builders (registerBatcher, the TEE authenticateBatchInfo path and sendTxWithFallbackAuth) still parse the ABI on every send and use RollupConfig.BatchAuthenticatorAddress directly, so "one reader" is really one read path. Exposing the address and a pack helper on the reader would put all BatchAuthenticator access in one place.
2. There's no metric for the publish gate. Something like batcher_publish_gate{state="active|mode_inactive|key_unauthorized|error"} would let us alert when neither batcher is active, which you can't see from the logs of two separate pods.