Zero batch size or parallel requests silently skips scans

**Describe the bug**

Passing `batch_size = 0` to Electrum or `parallel_requests = 0` to Esplora makes the script scan finish successfully without querying any scripts. A full scan returns empty transaction data and `last_active_indices`, even with a nonempty request. This can make a wallet restore appear empty until the configuration is corrected.

The same zero-size batching affects script sync in Electrum, and script/txid/outpoint sync in Esplora's blocking and async APIs. The public methods do not validate or document this case.

This issue was found by AI.

**To Reproduce**

Add `crates/esplora/tests/test_zero_parallel_requests.rs` and run `cargo test -p bdk_esplora --features blocking --test test_zero_parallel_requests`. No server is needed:

```rust
use bdk_chain::{bitcoin::ScriptBuf, spk_client::FullScanRequest};
use bdk_esplora::{esplora_client::Builder, EsploraExt};

#[test]
fn zero_parallel_requests_must_not_report_a_successful_scan() {
let client = Builder::new("http://127.0.0.1:1").build_blocking();
let request = FullScanRequest::builder_at(0)
.spks_for_keychain(0u32, [(0, ScriptBuf::new())]);

let response = client.full_scan(request, 3, 0);
assert!(response.is_err(), "scan skipped its script and returned {response:?}");
}
```

The assertion fails with an empty `Ok(FullScanResponse { ... })`. Electrum's `full_scan(request, 3, 0, false)` skips scripts through the equivalent empty-batch path.

**Expected behavior**

A nonempty scan or sync request should not be reported as successfully processed when a zero batching/concurrency parameter prevented its work. Zero values should have explicit, documented handling.

Start with crates/esplora/tests/test_zero_parallel_requests.rs and run cargo test -p bdk_esplora --features blocking --test test_zero_parallel_requests. Trace EsploraExt::full_scan and the corresponding Electrum full_scan and sync entry points, then cover the blocking and async paths named in the issue. Done means zero batching or concurrency values receive explicit handling, do not silently skip nonempty work, and are documented and tested.

Written by the indexing model from the issue text.