Reuse batch-sync connections and promptly retry peer progress

[philsippl]

Batch synchronization currently constructs a new HTTP client for every poll and waits a full second when a peer is briefly on the preceding batch. On the three-party CPU scan benchmark, this caused clusters of one-second stalls even though each matching pass took about 140 ms.

Reuse a shared HTTP client and its connection pool. For batch-ID conflicts, older IDs, and differing hashes, retry after 5 ms and double the delay up to 100 ms. Transport failures, unexpected HTTP errors, and malformed responses retain their one-second retry. Existing batch/hash checks and outer timeouts are preserved.

Validation: all 13 ampc-server-utils library tests pass; clippy with -D warnings passes. The new local HTTP regression test covers HTTP 409, a stale successful batch response, and a stale hash; it verifies eventual exact states/entries and connection reuse. In worldcoin/iris-mpc#2386, three r8g.24xlarge hosts running 128-request bursts against approximately 1.05 million records measured the following with 64 score cores and 32 runtime cores:

Native-prime path	Matching comp/s	Queued full-service comp/s after 16 warm-ups
MPC improvements, old synchronization	15,205,989	8,330,240
Same MPC, this synchronization fix	15,152,958	13,422,213
Repeat with this fix	15,162,452	13,434,131

The old-synchronization run contained clusters of approximately one-second stalls; these did not occur in the new runs' measured intervals. Median batch reception fell from 23 ms to 1 ms. Matching throughput is unchanged within measurement noise, as expected. Initial queue wait still varies: whole-burst rates from first publish were 12.31M and 10.76M comp/s for the new runs. These are finite synthetic service bursts with Moto, PostgreSQL, TLS, MPC, persistence, and all-party result delivery, not sustained production capacity measurements. Each run validated 384 agreeing responses. The integration PR pins this exact commit.