fix(archiver): batch multi-key point reads into one LMDB round trip

[spalladino]

Stack

Part of A-1817. Bottom to top, each PR targets the branch below it:

• fix(archiver): avoid loading full blocks during checkpoint ingestion #25279 spl/faster-block-ingestion -> merge-train/spartan-v5 — cheaper checkpoint ingestion, so writes hold the store for less time
• feat(kv-store): expose read-only lmdb transactions #25280 spl/kv-store-read-only-tx -> spl/faster-block-ingestion — adds readOnlyTransaction plus txId on the native GET / START_CURSOR
• fix(archiver): batch multi-key point reads into one LMDB round trip #25282 spl/batched-kv-gets -> spl/kv-store-read-only-tx — adds getMany / getManyAsync; depends on feat(kv-store): expose read-only lmdb transactions #25280 for txId on GetRequest <- this PR
• fix(archiver): speed up log-by-tag queries #25254 spl/faster-get-private-logs-by-tags -> spl/batched-kv-gets — faster tag scans; depends on fix(archiver): batch multi-key point reads into one LMDB round trip #25282 for getManyAsync on the log store's per-block reads
• fix(archiver): serve log-by-tag queries from read-only snapshots #25315 spl/log-store-read-only-snapshots -> spl/faster-get-private-logs-by-tags — moves the log store's reads onto snapshots; depends on feat(kv-store): expose read-only lmdb transactions #25280 for readOnlyTransaction

Context

Every getAsync on the lmdb-v2 kv-store costs a full JS→C++ msgpack round trip, and the archiver has hot paths doing one point read per tx effect or per log: getBlock awaited a sequential read per tx (120-tx block = 120 serialized round trips), and getNoteHashesAndNullifiers (the includeEffects path of getLogsByTags) issued one message per tx hash. The wire protocol's GET request already accepts an array of keys and the native handler returns one slot per key in order — nothing on the TS side used it.

Approach

• ReadTransaction.getMany(keys, { chunkSize }) sends the keys in GET messages of at most chunkSize keys (default DEFAULT_GET_CHUNK_SIZE = 1024), which bounds message size and how long one read holds its transaction; callers can override per call; WriteTransaction overrides it, resolving each key against the pending batch first (pending writes and removes behave exactly like N sequential get calls) and batch-fetching only the rest. The single-key get now shares the same pending-lookup helper.
• AztecAsyncMap.getManyAsync(keys) is added to the interface; lmdb-v2 maps use the batched read, other backends (lmdb-v1, sqlite-opfs, indexeddb, lmdb-v2 multimap) use a Promise.all of getAsync.
• Converted the archiver's N-point-read loops: getBlock's tx-effect loop, getNoteHashesAndNullifiers, and the per-block log reads behind getPrivateLogsForBlock/getPublicLogsForBlock. Warn messages, missing-key behavior, and output order are unchanged.

Measured (interleaved A/B, 3 runs each): getBlock on a 120-tx block 80–84ms → 64–71ms (~17% faster; most of the win is not interleaving deserialization between sequential awaits). getNoteHashesAndNullifiers with 100 hashes was already pipelined via Promise.all, so it drops 100 messages to 1 with a small wall-clock gain (~7%).

API changes

AztecAsyncMap gains getManyAsync(keys: K[], opts?: { chunkSize?: number }): Promise<(V | undefined)[]>; any external implementations of the interface need the method (a Promise.all over getAsync is a valid implementation).