feat(coprocessor): drift detection in gw-listener (M1)

[Eikix]

Summary

• Add opt-in drift detection to gw-listener by polling CiphertextCommits events
• Fetch the expected coprocessor tx-sender set from GatewayConfig when drift detection is enabled
• Track per-handle submissions in memory until the handle is complete or stale
• Persist the earliest open CiphertextCommits block and rebuild open-handle state from chain logs after restart
• Detect multiple digest variants for a handle and log the sender breakdown
• Compare consensus digests against the local ciphertext_digest row when local digests already exist
• Alert if all expected coprocessors submitted but no consensus event was observed
• Alert if consensus was reached but some expected coprocessors never submitted within a grace window
• Metrics: drift_detected, consensus_timeout, missing_submission

Scope Notes

• Restart recovery persists only one watermark: the earliest open CiphertextCommits block
• Open-handle state is rebuilt from chain logs on startup; it is not stored in Postgres as structured detector state
• Consensus mismatch remains stateless because it compares consensus against the local DB row
• This PR does not pause processing, fetch canonical ciphertexts, or wipe/recompute state

Test plan

• SQLX_OFFLINE=true cargo build -p gw-listener
• SQLX_OFFLINE=true cargo test -p gw-listener
• Manual: run gw-listener with --ciphertext_commits_address and --gateway-config-address
• Manual: restart gw-listener while a handle is still open and verify tracking resumes from the persisted watermark
• Manual: verify /metrics exposes drift_detected, consensus_timeout, and missing_submission

closes https://github.com/zama-ai/fhevm-internal/issues/1147

[mergify]

🧪 CI Insights

Here's what we observed from your CI run for d114dac.

🟢 All jobs passed!

But CI Insights is watching 👀