feat: support testnets

[rnbguy]

closes #440
closes #468

This is a feature branch to test our work on testnets manually.
This is required as madara (our e2e test devnet) is outdated than the starknet testnet.

[rnbguy]

Checked with starknet blocks post v0.14.0 upgrade on testnet and mainnet (mainnet seems to be halted right now. so tried with blocks till the halted height 1962873). there is no need for refactoring at our end for now.

but the block time has been reduced to 6 secs from 30 secs. we need to update the default BatchConfig for the packets relaying from Osmosis to Starknet.

[rnbguy]

we need to use 0.9 RPC endpoints, as that became standard in starknet 0.14.0. but I couldn't find a working RPC endpoint post-0.14.0 upgrade.

[rnbguy]

Looks like, starknet-core v0.16.0 started using is_multiple_of which is stabilized in Rust 1.87. and we are using Rust 1.81 to build the cosmwasm contract.

[rnbguy]

Hacking around dependencies and proxying RPC endpoints, I managed to get a concrete error from Starknet about ICS23: mismatched value. Probably the storage proof logic is broken or the RPC queries are inconsistent. Will wait until we have access to a proper Starknet RPC endpoint.

[rnbguy]

Looks like there is a bug in our code.

ibc-starknet/cairo-contracts/packages/core/src/connection/components/handler.cairo

Lines 251 to 257 in f85d4e1

	let expected_conn_end_on_b = ConnectionEndTrait::try_open(
	conn_end_on_a.counterparty.client_id.clone(),
	conn_end_on_a.client_id.clone(),
	msg.conn_id_on_b.clone(),
	conn_end_on_a.counterparty.prefix.clone(),
	conn_end_on_a.delay_period,
	);

It should use the connection ID of the counterparty at chain-B, which is the connection ID at chain-A.

   let expected_conn_end_on_b = ConnectionEndTrait::try_open( 
       conn_end_on_a.counterparty.client_id.clone(), 
       conn_end_on_a.client_id.clone(), 
-      msg.conn_id_on_b.clone(), 
+      msg.conn_id_on_a.clone(), 
       conn_end_on_a.counterparty.prefix.clone(), 
       conn_end_on_a.delay_period, 
   ); 

With this change, the bootstrap works without the ICS23: mismatched value error.

ps. to patch this, I upgraded the contract with the newer class hash. thus, I managed to test contract upgradability -- which works alright.

---

opened #473

[rnbguy]

I am getting an occasional error while batching:

...
2025-09-09T01:19:42.783433Z  INFO hermes: Successfully completed ICS03 ConnectionOpenAck on chain 393402133025997798000961 with ConnectionId `connection-30` f
2025-09-09T01:19:42.783518Z  INFO hermes: Starting ICS03 ConnectionOpenConfirm on chain `osmo-test-5` for clients `07-tendermint-73` and `08-wasm-4906`
2025-09-09T01:19:46.262268Z  WARN hermes: No divergence found while checking for misbehaviour
2025-09-09T01:19:46.362287Z ERROR hermes: failed to relay batch event: TypeUrlMismatchError { expected_url: "/ibc.lightclients.wasm.v1.ClientState", actual_ur
...

---

opened informalsystems/hermes-sdk#646