fix(cketh): don't panic when transaction receipt is not yet indexed

[Rachit2323]

Bug

When finalizing ETH withdrawals, the minter checks how many transactions were finalized on-chain, then fetches receipts for each one. These are two separate RPC calls — not atomic.

If an RPC provider returns null for a receipt (not yet indexed, transient lag), the code hits Ok(None) and silently skips that withdrawal. But then the assert_eq! below expects every withdrawal to have a receipt. The counts don't match and the whole finalization timer panics — blocking all pending ETH withdrawals until the next tick.

Fix

Replace assert_eq! with a log + early return. If the counts don't match, log a warning and retry on the next timer tick instead of panicking.

Tests

The existing test should_not_finalize_transaction_when_receipts_do_not_match continues to pass. The fix is safe — a mismatch is now treated as a transient RPC inconsistency, not a hard failure.

[github-actions]

Run on 8c89ea6 URL: https://github.com/dfinity/ic/actions/runs/31414927516

[zeropath-ai]

✅ No security or compliance issues detected. Reviewed everything up to 5c75fa2.

Security Overview

• 🔎 Scanned files: 1 changed file(s)
• 🔗 Scan Link: https://zeropath.com/app/repositories/783a9bd4-fb4e-4e10-ab3c-c2fb2ddfb92f?scanId=a0cd2ccb-04fa-4bc7-be4f-42403c0b49c6&codeScanTypes=PrScan&tab=issues

Detected Code Changes

Change Type	Relevant files
Bug Fix	► rs/ethereum/cketh/minter/src/withdraw.rs     Fix mismatch handling by logging a mismatch between expected and actual finalized withdrawal IDs and returning early to allow retry