chore(via-btc-client): expose concrete RPC method names in retry metrics

[romanornr]

Summary

This observability-only PR changes the Bitcoin RPC retry wrapper to label retries / max-retry metrics with the concrete RPC method name instead of the generic RPC call label.

Why

During Via main testnet via-l1-indexer investigation, the live metric exposed only:

• via_btc_client_rpc_max_retries_exceeded{method="RPC call"}

That made it impossible to tell which exact Bitcoin Core RPC method was timing out from production metrics alone.

This PR keeps behavior unchanged and only improves operator visibility by emitting concrete method names such as:

• get_block_count
• get_block_by_height
• get_block_stats
• get_raw_transaction
• get_raw_transaction_info
• etc.

Scope

• no business-logic change
• no retry-policy change
• no config change
• observability only

Incident context

This came out of a Via main testnet investigation where:

• via-l1-indexer repeatedly logged transport timeouts to the Bitcoin RPC service
• direct spot-checks from the same pod showed multiple Bitcoin RPC methods working, but the production metric was too generic to identify the exact failing method

This PR is intended to make the next live incident materially easier to localize.

[gemini-code-assist]

Code Review

This pull request updates the BitcoinRpcClient in rpc_client.rs to include an operation_name parameter in the retry_rpc method. This change allows for more descriptive logging or monitoring by passing a specific string identifier (e.g., "get_block_count", "send_raw_transaction") to the underlying with_retry function. All internal calls to retry_rpc have been updated to provide these identifiers. I have no feedback to provide.