feat(ops): reject an oversized --key list before the network does

[0dillon]

Summary

extendViaFootprint guards the empty case but has no upper bound on the number of ledger keys in
one extendFootprintTtl. A long --key list is built into a transaction, simulated, and rejected
by the network for exceeding its resource limits.

The operator gets a network error describing resource usage instead of being told their key list is
too long. Note that src/rpc/ttl.ts already chunks reads at 100 keys per request, so the repository
has a precedent for bounding this locally rather than discovering the limit remotely.

Acceptance Criteria

• A documented maximum, established by finding where the transaction actually stops being
  accepted rather than by picking a round number.
• Exceeding it fails locally with a message naming the count and the maximum, before any
  simulation or network call.
• The limit is stated in lkeep extend --help and in the README's --key description.
• A test covers the boundary: the maximum accepted, one over rejected.

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.