test(rpc): drive readTtl's chunking loop past a single request

[0dillon]

Summary

readTtl chunks its key list at MAX_KEYS_PER_REQUEST = 100 because the RPC caps how many keys one
getLedgerEntries call accepts. No test has ever sent it more than a handful, and the live checks
run during development only ever sent three keys.

Termination is structurally obvious. What is untested is everything else the loop does: that every
chunk is requested, that entries from all chunks are collected rather than the last one winning,
that latestLedger is reconciled across responses, and that output order still matches the
requested order — which the scan table depends on.

Acceptance Criteria

• A fake server records the keys of every getLedgerEntries call.
• A test with more than 100 keys asserts the number of calls and that the union of requested
  keys equals the input exactly, with no key sent twice.
• A test asserts readings come back in the requested order across a chunk boundary.
• A test covers chunks reporting different latestLedger values and asserts which one wins.
• A test covers exactly 100 keys — one full chunk, no second request.

Tech Stack

TypeScript 5.7 on Node 22+ (CI runs 22 and 24), ESM with moduleResolution: "NodeNext" — relative
imports need the .js extension. @stellar/stellar-sdk is pinned to an exact version; verify RPC
API shape against the installed copy, not against documentation. Tests are Vitest under test/ and
run without a network. npm run format:check, npm run lint, npm run build and npm test must
all be clean.