Make sure that settlement can time out

[luckysori]

This CI job was stuck for a while: https://github.com/arkade-os/rust-sdk/actions/runs/25038966785/job/73337868864#step:18:48.

[arkanaai]

Codebase Context

The settlement protocol is orchestrated in two functions in ark-client/src/batch.rs:

• join_next_batch() (~line 1386) — used by regular settle() / settle_vtxos() / collaborative_redeem()
• settle_delegate() (~line 554) — used for delegated settlement flows

Both functions open a gRPC event stream and spin in a loop { match stream.next().await { ... } } waiting for the sequence: BatchStarted → TreeTx → TreeSigningStarted → TreeNonces → BatchFinalization → BatchFinalized.

The CI hang linked in the issue is almost certainly one of these loops waiting forever because an expected event never arrived (server dropped the stream, timed out on its side, or got stuck mid-round).

Individual network calls (register intent, confirm registration) are already wrapped in timeout_op() from ark-client/src/utils.rs, but the event-listening loop itself has no timeout.

---

Acceptance Criteria

• join_next_batch() does not hang indefinitely — it times out with a clear error if the batch takes too long (overall wall-clock timeout)
• settle_delegate() has the same protection
• Timeout duration is configurable (via the existing Client::timeout field or a dedicated batch_timeout)
• The timeout error is distinct from other errors so callers can retry vs. abort
• E2E test for settlement asserts completion within a bounded time (no #[ignore]-only coverage)

---

Suggested Approach

Wrap the entire event loop with a global deadline using tokio::time::timeout:

// join_next_batch / settle_delegate inner loop
tokio::time::timeout(self.inner.timeout, async {
    loop {
        match stream.next().await {
            Some(Ok(event)) => { /* existing state machine */ }
            Some(Err(e)) => return Err(e.into()),
            None => return Err(Error::ark_server("batch event stream closed")),
        }
    }
})
.await
.map_err(|_| Error::timeout("settlement", self.inner.timeout))??;

Alternatively, use tokio::select! on each stream.next() with a per-event deadline (similar to how vtxo_watcher.rs uses periodic ticks + a stop signal) — this gives finer-grained diagnostics about which phase timed out.

The existing timeout_op helper in utils.rs could be extended or reused for this.