[server] Restore KV minRetainOffset on follower restart

[gyang94]

Summary

• Restore follower minRetainOffset from the latest committed KV snapshot when KV followers are handled in makeFollowers.
• Coalesce pending restores into one asynchronous task per TabletServer, keeping ZooKeeper access outside the replica state-change lock.
• Bound ZooKeeper pressure with 32-bucket client batches, the configured max-inflight limit, startup jitter, and exponential retry backoff.
• Distinguish confirmed-empty snapshots from unresolved reads, and ignore stale results after notifications, role changes, replica replacement, or shutdown.
• Fixes [server] Restore KV minRetainOffset on follower restart #4054

Test Plan

• ZooKeeperClientTest: 23 tests passed.
• ReplicaManagerTest: 41 tests passed.
• mvn -o -pl fluss-server -DskipTests -Dfast verify passed (Checkstyle 0 violations and Spotless passed).

🤖 AI-assisted changes - reviewed by human developer

[wuchong]

Could we avoid this separate ZooKeeper-backed recovery state machine by piggybacking the committed minRetainOffset on follower FetchLogResponses? The leader advances this value only after a KV snapshot is committed, and follower fetches already retry continuously (including empty long-poll responses), so every successful fetch can idempotently apply updateMinRetainOffset. The existing notification can remain the fast path, while FetchLog becomes the anti-entropy and restart-recovery path.

This follows Kafka's pattern of propagating a logical cleanup boundary by logStartOffset in FetchResponse. Fluss should use a separate optional min_retain_offset field rather than overload log_start_offset: the former is snapshot-derived deletion permission. This would remove the complex logic in this PR: pending map, ZooKeeper batch reads, scheduler/backoff, and replica-identity fencing while preserving eventual local cleanup progress.