Batch Electrum witnesses during RGB transfer import

[Jainakin]

Summary

• collect unique historical witness IDs immediately before accept_transfer and save_new_asset validation
• resolve those witnesses through rgb-ops native Electrum request batching on the wallet's existing authenticated Electrum connection
• expose the immutable materialized batch response through a resolver view shared by validation, contract import, and transfer acceptance within that call
• delegate non-batched witnesses to the existing resolver without memoizing fallback results
• keep Esplora behavior unchanged

Design constraints

This PR intentionally contains no persistent cache, memoizing resolver cache, worker pool, or new background executor. The response map is the direct materialized result of one Electrum batch; it lives only for the enclosing synchronous wallet operation and is dropped afterward. Fallback lookups are not cached.

The previous cache/prefetch experiment, benchmark fixture, and delay proxy have been removed from the final diff. The runtime performance change is limited to the operation-local Electrum batch resolver in src/utils.rs, its use in src/wallet/rust_only.rs, and the electrum-client API adjustment in src/wallet/indexer.rs. The remaining diff keeps the root, C-FFI, and UniFFI workspaces aligned to the same audited RGB dependency graph through manifest and lockfile updates.

Motivation and measured result

A controlled 88-history consignment was replayed through the exact RGB-lib validation/import/acceptance path.

Modeled 400 ms RTT workload	Serial	Batched	Improvement
Full validate/import/accept	214.691 s	3.120 s	~68.8x

On localhost the complete path moved from 948 ms to 628 ms. The RTT run used a deterministic local delay proxy and is not a claim about production Signet infrastructure.

Dependency alignment

rgb-ops 0.11.1-rc.11 uses electrum-client 0.25, so this PR aligns RGB-lib and its standalone binding workspaces with:

• rgb-* 0.11.1-rc.11
• rgb-strict-* 1.0.2
• bdk_electrum 0.24
• electrum-client 0.25

The branch is temporarily pinned to the reviewed Electrum-only commit in rgb-protocol/rgb-ops#18. That pin is a stacking mechanism only and must be replaced by an official rgb-ops release before this PR merges.

Correctness behavior

• batching happens before RGB runtime mutation
• transaction IDs and confirmation-derived heights are verified by rgb-ops
• transport/protocol batch failures, missing-transaction recovery, malformed merkle cardinality, and merkle-height drift retain the original serial resolver semantics
• malformed transaction data and identity mismatches fail closed
• validation, contract import, and runtime acceptance observe the same immutable per-call batch result
• fallback resolutions are deliberately not cached

Validation

Passed locally on the final pin:

• cargo fmt --all -- --check
• operation-local resolver tests: 2 passed
• Electrum-only clippy with -D warnings
• C-FFI standalone workspace clippy
• UniFFI standalone workspace clippy
• locked UniFFI dependency metadata validation
• controlled 88-history resolver and full acceptance benchmarks

The final clean head is green across all 23 required Linux/macOS/Windows build, MSRV/stable/nightly, Electrum, unchanged Esplora, no-default-feature, docs, lint, feature-test, and all-feature coverage checks: https://github.com/UTEXO-Protocol/rgb-lib/pull/79/checks

The upstream all-feature integration harness cannot complete on this Apple Silicon host because blockstream/esplora:latest exits immediately with a zero-byte runit_boot.sh, poisoning the shared test initializer. Linux CI is therefore a required merge gate; this PR does not claim that local cascade as passing or as a code regression.

Scope and rollout

This reduces historical witness network round trips for native Electrum only. It does not batch Esplora or WASM resolution, move validation outside LDK peer locking, alter transfer persistence, or implement channel-funding recovery.

Production rollout must exercise the exact authenticated Electrum deployment. Unsupported or rejected native batches safely fall back to serial resolution but will not deliver the latency improvement.