Do not treat pending-block receipts as confirmed (fixes #165)

[JSap0914]

Problem

send_transaction_with_confirmation (and send_raw_transaction_with_confirmation) could report a pending transaction as confirmed.

When confirmations == 0 the function skipped wait_for_confirmations entirely and returned the first receipt from eth_getTransactionReceipt. As noted in #165, a node returns a receipt with blockHash/blockNumber set to null for a transaction that is only part of a pending block. That pending receipt was returned as the confirmed result instead of waiting for the transaction to actually be mined.

Fix

Always run wait_for_confirmations, including for confirmations == 0. wait_for_confirmations already only treats a receipt as confirmed once block_number is present (via transaction_receipt_block_number_check), so the call now waits for the transaction to be mined into a block before returning its receipt.

Test

Added a mocked-transport regression test (test_send_transaction_with_confirmation_ignores_pending_receipt) that drives a pending-then-mined sequence with confirmations == 0: the first eth_getTransactionReceipt returns a receipt with null blockHash/blockNumber (must not confirm), polling continues, and the subsequently mined receipt is returned. The test fails against the previous code (it returned the pending receipt without ever creating a block filter) and passes with this change.

running 2 tests
test confirm::tests::test_send_transaction_with_confirmation ... ok
test confirm::tests::test_send_transaction_with_confirmation_ignores_pending_receipt ... ok

cargo fmt -- --check is clean; no new clippy warnings introduced.

Fixes #165