WIP: batch smart client design

### 🚀 Feature Description and Motivation

Batch execution streams a large number of OpenAI-compatible inference requests into a model-serving backend. The shape of that backend varies widely:
- a single direct model server,
- a single gateway / load-balanced address, (Kubernetes)
- multiple direct backend endpoints,
- endpoints discovered dynamically (Kubernetes, Consul, static config).

The driver should be able to say "send this stream of requests" and stay oblivious to replica count, endpoint churn, and backend topology. The smart client owns that complexity.

### Topology Landscape

### Architecture Overview

```mermaid
flowchart LR
DRV[BaseJobDriver]
ENG[DispatchEngine.run]
SRC[EndpointSource]
RT[Router]
CH[Channel]
SINK[on_result]
STORE[(durable
output / error)]
PROG[(progress
ledger)]

DRV -- "iter_claimed_requests" --> ENG
ENG -- "channels()" --> SRC
ENG -- "pick" --> RT
RT --> CH
CH -- "HTTP" --> BACKEND[(backend)]
CH -- "Response | InferenceError" --> ENG
ENG -- "on_result" --> SINK
SINK --> STORE
SINK --> PROG

```

Responsibility split:
- DispatchEngine owns bounded concurrency, endpoint selection, retry, and pacing.
- Batch driver owns claim/complete progress, durable storage, deadline / cancellation, and finalization.
- EndpointSource owns topology and capacity discovery.
- Channel owns one HTTP transport plus structured error reporting.

### Use Case

make sending request easier in batch

### Proposed Solution

_No response_