Support cumulative confirmations for BTC/Zcash deposits

[olga24912]

The satoshi-bridge contract now tiers deposit confirmations by the block-cumulative amount (Near-One/btc-bridge#48) and exposes a get_required_confirmations view (Near-One/btc-bridge#70).

• Deposit pre-check asks the contract via the view; falls back to the local formula only on MethodNotFound (old contract), so both versions work without config flags.
• Refund request pre-check now requires max_required_confirmations() (max tier + max delta), mirroring the new contract.
• Withdraw, active UTXO management and refund finalize are unchanged.

[claude]

Pull request overview

This PR adapts the SDK to the satoshi-bridge contract's new block-cumulative deposit confirmation tiering (btc-bridge#48) and its get_required_confirmations view (btc-bridge#70). Deposit pre-checks now ask the contract for the live requirement (falling back to the local amount-tier formula only on old contracts), and refund-request pre-checks now demand the unconditional maximum depth to mirror the new contract. Withdraw / active-UTXO / refund-finalize keep the amount-tier formula, which is stable across contract versions.

Changes:

• Split ensure_sufficient_btc_confirmations into three intent-specific pre-checks over a shared ensure_btc_light_client_depth helper: amount-tier (unchanged flows), deposit (view-backed), and refund-request (max depth).
• Added NearBridgeClient::get_required_confirmations_for_deposit calling the get_required_confirmations view, with a MethodNotFound-only fallback to the local formula.
• Added BtcConfirmationContext::max_required_confirmations (max strategy tier + larger delta, whitelist-agnostic).
• Added NearRpcError::is_method_not_found to distinguish a missing contract method from transport failures / in-method panics.
• Version bumps + Cargo.lock.

Reviewed changes

Per-file summary

File	Description
bridge-sdk/near-rpc-client/src/error.rs	New is_method_not_found helper (matches ContractExecutionError whose vm_error contains MethodNotFound) + unit tests.
bridge-sdk/bridge-clients/near-bridge-client/src/btc.rs	New max_required_confirmations and view-backed get_required_confirmations_for_deposit with MethodNotFound fallback; doc-comment updates; unit tests.
bridge-sdk/connectors/omni-connector/src/omni_connector.rs	Extracted ensure_btc_light_client_depth; deposit flow → _for_deposit, refund-request flow → _for_refund_request; withdraw/active-UTXO/refund-finalize unchanged.
bridge-cli/Cargo.toml, .../near-bridge-client/Cargo.toml, .../omni-connector/Cargo.toml, .../near-rpc-client/Cargo.toml, Cargo.lock	Version bumps.

Findings

I verified the routing exhaustively: the three remaining ensure_sufficient_btc_confirmations call sites (omni_connector.rs:775 verify_withdraw, :827 verify_active_utxo_management, :990 verify_refund_finalize) all correctly keep the amount-tier path with uses_extra_msg_path=false; deposit (:720) and refund-request (:887) are the only flows moved. max_required_confirmations correctly returns max(strategy.values()) (the true ceiling of base_confirmations, regardless of tier monotonicity) plus the larger delta, ignoring whitelists. The NearRpcError → BridgeSdkError conversion exists (result.rs:25), so the err.into() fallback compiles. No blocking issues.

Non-blocking (verification / robustness):

• near-bridge-client/src/btc.rs:1408 — serde_json::from_slice::<u64>(&response) assumes the view returns a bare JSON number. If get_required_confirmations returns a U64 (string-wrapped) on-chain, this parse fails at runtime on every deposit against a new contract (the error propagates rather than falling back, since it isn't MethodNotFound). Worth a quick confirm that the contract's return type is a plain u64.
• near-rpc-client/src/error.rs:44 — is_method_not_found relies on substring-matching vm_error.contains("MethodNotFound"). There's no structured error code available, so this is the pragmatic choice and the tests pin the current nearcore format; just flagging that a future nearcore error-string change would silently disable the old-contract fallback.
• omni_connector.rs:720 vs :887 — the deposit pre-check now issues an extra view RPC per attempt (by design, "must not be cached"); combined with the existing extract_btc_proof/light_client calls this adds a round-trip on each retry. Fine functionally; noting in case retry cadence matters for relayers.

✅ Approved