[Store] parallelize per-bucket reads in BatchLoad via worker pool

[leaves-zwx]

BatchLoad previously iterated buckets sequentially, issuing one set of preads per bucket before moving to the next. Each bucket is a separate file with no shared read state, so this serialization was purely artificial; on a single NVMe device with default 256 KiB bucket gaps it limited read throughput to ~1.4 GB/s while the device is capable of ~4-5 GB/s.

Fix: mirror the WriteBucket parallelization pattern from commit e738cfd. Capture the per-bucket body as a lambda returning std::optional (nullopt on success, error code on unrecoverable failure) and dispatch the buckets across a bounded set of worker threads. Workers pull bucket indices from a shared atomic counter and stop as soon as one bucket returns a fatal error, so the caller joins all workers before returning. The serial path is retained when offload_read_threads<=1 or there is only one bucket, preserving the legacy behavior with no thread overhead.

Thread safety:

• bucket_read_plans is snapshotted into a vector of (bid, plans*) pairs before workers start; the unordered_map is never touched concurrently.
• Each bucket opens its own fd via OpenFile; StorageFile instances are not shared across worker threads.
• batch_object.at(key).ptr writes target disjoint keys (a key belongs to exactly one bucket), so different workers mutate distinct map values.
• VLOG is thread-safe via glog.

Env var (added): MOONCAKE_OFFLOAD_READ_THREADS (default 4). Set to 1 to fall back to the legacy serial loop. Mirrors MOONCAKE_OFFLOAD_WRITE_THREADS.

Also adds a batchload_dispatch VLOG so the parallel/serial decision and effective thread count are visible in stage-4 diagnosis logs.