Support cairo_native in rpc-client

[heemankv]

Summary

• wire rpc-client's existing cairo_native feature through to blockifier/cairo_native
• handle RunnableCompiledClass::V1Native when computing compiled class hash v2
• enable rpc-client's cairo_native feature from generate-pie
• align SNOS's direct reqwest dependency with starknet-rust-providers so rpc-client can construct a custom HttpTransport client
• bound SNOS RPC transport calls with connect/request timeouts so the retry wrapper can recover instead of hanging forever

Why

Madara now builds madara and orchestrator in a unified workspace dependency graph. In that graph, blockifier is built with cairo_native, which exposes RunnableCompiledClass::V1Native.

Upstream rpc-client still assumed only V0 / V1 in get_compiled_class_hash_v2, so downstream consumers had to patch SNOS locally. This PR started as the smallest upstream fix needed to let downstreams consume SNOS without a vendored rpc-client override.

After wiring Madara directly to this branch and running orchestrator::tests::jobs::snos_job::test_process_job against Sepolia block 2934726, there was still a separate runtime issue: the native path could hang indefinitely on the first get_nonce_at state read. The underlying JSON-RPC call returned immediately with curl, but SNOS's Rust transport had no bounded connect/request timeout, so a stuck HTTP future never errored and the retry logic in state_reader never regained control.

The additional timeout fix in this branch addresses that runtime failure mode. Aligning SNOS's direct reqwest dependency with starknet-rust-providers was required to use HttpTransport::new_with_client(...) with a bounded client.

Validation

• cargo check -p rpc-client
• cargo check -p rpc-client --features cairo_native
• cargo check -p generate-pie
  • currently blocked in this environment because apollo_starknet_os_program requires cairo-compile from the sequencer venv/toolchain (Failed to get cairo-compile version: No such file or directory)
• Madara exact orchestrator test with SNOS pinned to this branch/commit:
  • cargo test -p orchestrator --features testing tests::jobs::snos_job::test_process_job -- --exact --nocapture
  • passed locally once SNOS was consumed from this branch with the timeout change

[prkpndy]

LGTM

[prkpndy]

should we increase it? might be small for larger proofs on slow connections!