fix(fault-proof): robustness follow-ups to #865 + cost-estimator parity

[seolaoh]

Summary

Three independent follow-ups to #865 in the proposer, plus a cost-estimator flag that builds on #869 to align the estimator's split behavior with how the proposer actually proves.

1. fault-proof: warn-log L1 head regression in sync_state

Distinguish the two skip cases: WARN when confirmed_number moves backwards (load-balanced backend regression or deep reorg) so operators can detect unhealthy backends, DEBUG for the normal "L1 hasn't ticked" path. Pure observability; no behavior change.

2. fault-proof: reset creation guard when tracked game is pruned

When sync_games prunes future games due to abnormal cache states (backup restore into a shorter chain, deep L1 reorg, factory reset), the duplicate-creation guard could point at a game that no longer exists. Without resetting, should_create_game blocks indefinitely. Reset is gated on the guarded address being among the entries this prune actually removes — checking "absent from post-prune cache" instead would over-clear when a just-created game hasn't been added to the cache yet, allowing duplicate submission.

3. fault-proof: pre-flight on-chain status check before prove/resolve/claim

With sync_l1_confirmations > 0, the cache lags by ~sync_l1_confirmations × block_time. During that window, recently confirmed prove/resolve/claimCredit txs are invisible to the cache, so should_* flags re-fire and the proposer re-submits — wasting prover-network spend (full range + agg proof regeneration) and gas (reverted txs).

Each path now does one eth_call at latest before submission:

• resolve_games: skip if GameStatus != IN_PROGRESS
• claim_bonds: skip if credit(signer) == 0
• should_skip_proving: skip if ProposalStatus is *ValidProofProvided or Resolved (covers both already-proven and timeout default-loss; Resolved is set whenever GameStatus moves out of IN_PROGRESS)

On RPC failure the check logs warn and proceeds, so transient backend issues don't block legitimate work.

4. scripts: add --no-safe-head-split to cost-estimator (follow-up to #869)

#869 fixed --batch-size precedence so the flag is honored when explicit --start/--end are given. But with SafeDB active, the splitter still cuts at span batch boundaries via split_range_based_on_safe_heads, regardless of the now-correct effective_batch_size. The proposer with RANGE_SPLIT_COUNT=1 (default) does not split that way — it produces one range proof per proposal interval. --no-safe-head-split forces split_range_basic so the estimator partitions only by --batch-size, giving a closer estimate of the per-segment cost the proposer actually incurs on the prover network.

Test plan

• cargo check --all-targets --all-features --tests && cargo fmt --all -- --check && cargo clippy --all-features --all-targets -- -D warnings -A incomplete-features
• Manual: cost-estimator with --no-safe-head-split produces a single batch instead of N span-batch-aligned chunks