ZKDisputeGame: Handle address(0) bond credit claiming via monitoring or contract change

[ajsutton]

Context

In ZKDisputeGame, when a parent game resolves as CHALLENGER_WINS and the child was never challenged, claimData.challenger is address(0). The resolve() function assigns totalBonds to normalModeCredit[address(0)] — the bond is effectively "burned" by crediting the zero address.

However, nobody will call claimCredit(address(0)) to actually move the funds through the DelayedWETH two-phase withdrawal, so the ETH remains stranded in DelayedWETH indefinitely.

This was identified during review of #19606:
#19606 (comment)

Options Discussed

1. Monitoring approach (current plan): Update monitoring to account for the fact that address(0) credits will never be claimed, so they don't show up as anomalies. The ETH stays in DelayedWETH — monitoring just needs to understand this is expected.

2. Contract-level approach: Piggyback on other claimCredit() calls to automatically process address(0) credit at the same time. Downside: makes the code messier.

3. Automatic burn in resolve(): Not feasible due to DelayedWETH's two-phase withdrawal — both phases can't happen in a single transaction.

Acceptance Criteria

• Decide on approach (monitoring adjustment vs contract change)
• If monitoring: update dispute-mon to expect that address(0) credit in ZK games is never claimed, so it doesn't flag as an anomaly
• If contract: implement and test the piggyback approach in ZKDisputeGame
• Ensure monitoring correctly accounts for ETH held in DelayedWETH from ZK game bond burns

Related

• dispute-mon: Implement monitoring for ZK games #18424 — broader ZK game monitoring issue
• feat: new zk dispute game #19606 — ZKDisputeGame implementation PR where this was identified