fix: F-2026-18139 | [Dual Defense] Cross-RPC Height Skew Can Underflow Confirmation Counts and Prematurely Finalize Inbounds

[Aman035]

• Added a checked helper common.ConfirmationDepth(latest, tx). When the latest height is behind the tx height (cross-RPC skew), both EVM and SVM confirmers defer the event (keep it PENDING and log at debug) instead of confirming on an underflowed depth.
• Removed the dead uint64 >= 0 fallback and moved the registry-zero decision into applyDefaults.
• Added a push_network config flag. On testnet a registry depth of 0 is honored as an instant route; on mainnet it falls back to a safe depth (fast 5, standard 12). Unset is treated as mainnet.
• SVM GetTransaction now pins CommitmentFinalized explicitly.
• Added tests: skew defers, mainnet-zero falls back, testnet-zero is honored.

Where our approach differs from the recommendation

• The recommendation was to flip the EVM check from >= 0 to > 0. We deleted the fallback instead and gated zero behind push_network, because zero is now a valid, explicit mode (testnet instant routes) rather than always a misconfiguration. The intent - never silently run at zero on mainnet is fully met.
• Same-backend pinning and median/quorum height across RPC backends were not implemented. The checked-subtraction guard already neutralizes the skew on its own, so these would only be redundant hardening.

[Aman035]

Rejecting zero values in registry validation - @0xNilesh I believe uregistry should also have this check as mentioned in recommendation guarded by testnet & mainnet configuration