fix(core): release waitForTransaction observers and port viem's wait, retry and cache fixes

.changeset/wait-for-transaction-leaks.md

@@ -0,0 +1,9 @@
+---
+'@bigmi/core': patch
+---
+
+Keep the shared block watcher alive when a `waitForTransaction` times out. When a wait reached its `retryCount` timeout and the same block callback then found the transaction confirmed or replaced, or failed to fetch the block, its internal `done` ran a second time. That second pass ran the watcher's cleanup while another wait on the same client still listened, so that wait and every later wait on the client never settled. It could also settle a newer wait on the same txId with the stale error of the first one. `done` now runs at most once, and an observer's `unwatch` is a no-op once its own listener is gone.
+
+Release the observers of a settled `waitForTransaction`. A wait that joined another wait on the same txId, such as a resumed run, stayed in the module-level `listenersCache` with its callbacks after both settled, and a third wait on that txId joined it and never settled. Every finished wait also left an empty `listenersCache` key behind, one per txId. Each wait now removes its own listener when it settles. When the last listener leaves, `observe` drops the key and its `cleanupCache` entry and runs the cleanup, which removes the observer from the shared block watcher. A wait now joins another wait on the same txId only when both use the same `confirmations`, `pollingInterval`, `retryCount`, numeric `retryDelay` and `senderAddress` (a `retryDelay` function is not compared), so it no longer runs with the options of the wait it joined, such as resolving at 1 confirmation when it asked for 3.
+
+Make the `timeout` option of `waitForTransaction` end the wait. The timer only rejected the promise: it was never cleared and the block watcher kept polling, so a wait whose `getblockcount` never succeeded polled until the page or process ended. The timeout now rejects and removes only its own wait, so another wait on the same txId with a longer timeout or none keeps waiting, and the shared block watcher stops once no wait listens to it. Every way a wait settles clears its timer.

.changeset/wait-for-transaction-viem-parity.md

@@ -0,0 +1,11 @@
+---
+'@bigmi/core': patch
+---
+
+Stop `waitForTransaction` from reporting the awaited transaction as its own replacement. When `getrawtransaction` still reported the transaction unconfirmed but `getblock` already listed it, the replacement search matched the transaction itself, because it spends the same inputs, and called `onReplaced` with it. A replacement that `getrawtransaction` reported with no confirmations also resolved the wait at once, and a replacement that needed more confirmations resolved it in a later block without `onReplaced`. The search now skips the awaited txid, a replacement without confirmations keeps the wait polling, and `onReplaced` fires once, when the replacement has enough confirmations. It reports the awaited transaction as `replacedTransaction` and finds the reason against it, also when the replacement replaced an earlier replacement that left the chain.
+
+Settle `withRetry` when `shouldRetry` or the `delay` function throws. The throw rejected an internal attempt that nothing handled, so the returned promise stayed pending and the error surfaced only as an unhandled rejection. `withRetry` now rejects with that error. A `retryDelay` function of `waitForTransaction` that threw hung the wait in the same way; the wait now rejects with that error.
+
+Wait for every confirmation of a mined transaction in `waitForTransaction`. The `retryCount` block budget also counted the blocks after the transaction was mined, so a wait for more confirmations than the budget had left rejected with `WaitForTransactionReceiptTimeoutError` while the transaction was confirming: with the default `retryCount` of 10, a wait for 6 confirmations rejected if the transaction was mined 6 or more blocks after the wait started. The budget now counts only the blocks in which the transaction, or the replacement it tracks, is not mined or the height of its block is unknown. An unmined transaction still rejects on the same block as before.
+
+Evict the least recently used key from the internal `LruMap` that holds the in-flight requests of request deduplication. A key that was set again kept its old place, a read moved a key to the newest place only when its value was not `undefined`, an empty-string key was never evicted, and the eviction read the keys through the subclass, which viem reports can give a stale iterator on iOS 18 JavaScriptCore. A key that is set again or read now becomes the newest, the oldest key is evicted also when it is an empty string, and the eviction reads the keys of the base `Map`. This matters only when more than 8192 deduplicated requests are in flight at once.