Add Node.js benchmark engine (valkey-glide-node, ioredis, iovalkey)

[jamesx-improving]

Summary

Adds a Node.js benchmark engine (node/, TypeScript) with three drivers:
valkey-glide-node, ioredis, and iovalkey — plus recording for
server-free tests. Follows docs/ADDING_LANGUAGE.md, with Java as the
reference implementation.

Fixes #12

What changed

Area	Files	What
node/	48	The engine: config parsing, key generation, rate limiter, HDR metrics, NDJSON writer, four drivers, 124 tests
configs/	11	Driver configs (default / high-throughput / example) + node-driver-comparison matrix
docs/	4	New BENCHMARKS_NODE.md; ARCHITECTURE, CONFIG_SPECIFICATION, ADDING_LANGUAGE updates
scripts/	3	DRIVER_ENGINE_MAP + both graph generators' driver maps
Makefile, .github/, infra/, config-editor/, README.md	5	Make targets, benchmark-node CI job, Node block in provision.sh, editor driver list

Concurrency model: one event loop, one client per connection, one worker per
connection. pipeline_depth > 1 gives each connection that many independent
in-flight slots. The per-phase request budget is shared across workers and
claimed one request at a time, matching Java's AtomicLong rather than
pre-splitting it — so a slow connection cannot cap the run.

Driver id note: the GLIDE id is valkey-glide-node, deliberately not bare
valkey-glide. The latter is already Java's in the global DRIVER_ENGINE_MAP,
and reusing it would silently reroute Java's glide runs to the Node engine.

Cross-engine parity — verified against Java, not assumed

• Key sequences byte-identical. 79,000 keys diffed against Java's real
  KeyGenerator across both algorithms, 1–16 workers, prime keys_count, and
  prefix-width edge cases. javaRandom.ts ports java.util.Random using
  BigInt (the 48-bit LCG multiply reaches ~2^83, past what a JS number holds
  exactly) and is anchored to new Random(0).nextInt() == -1155484576.
• HDR payloads decode in Java. org.HdrHistogram.Histogram reads our
  payload_b64 with matching count and percentiles. The payload is
  encodeIntoCompressedBase64() used directly — it is already base64, and
  encoding it twice produces something Java cannot read.
• summary.min/max match Java's quantization. Java returns the bucket's
  equivalent bounds; hdr-histogram-js' minNonZeroValue/maxValue return the
  raw sample, and they diverge above ~1000µs (50000µs reads back as 50015 in
  Java). Uses getValueAtPercentile(0)/(100) instead, which match exactly.
• PING does not consume a key, matching Java's PingCommand, so mixing PING
  into a workload does not shift the key sequence.

Node-specific fairness controls

These have no analogue in the other engines and would otherwise make results
incomparable:

• enableAutoPipelining: false on ioredis/iovalkey — it batches commands issued
  in the same event-loop tick, which would inflate throughput while looking like
  a driver win.
• retryStrategy: () => null — ioredis' default retries forever, so a wrong host
  would hang a run instead of failing it, and a mid-phase reconnect would fold
  connection setup into request latency.
• Uniform string decoding across all three drivers; SET payloads allocated once
  per command object, not per request.
• Sub-millisecond rate limits yield via setImmediate, since setTimeout clamps
  to ~1ms (a 100k rps limit is a 10µs interval).

Test plan

Unit + integration (124 tests, all passing):

make node-unit-test                       # 83 tests, no server
make node-integration-test                # recording driver + live-server per driver

Full automation sweep on AWS — node-driver-comparison, 3 drivers × 5
connection counts × 5 iterations:

job:      node-full-bench-20260908-235705-vrzjrp   (commit a8fb0c7)
instance: m5.2xlarge, us-east-1, Amazon Linux 2023 x86_64
result:   75/75 cells, 0 failed, 0 errors, status: succeeded
provision 4m32s · sweep 19m25s · self-terminated

This exercised the whole path: clone → provision.sh → sweep → graphs → S3.
Coefficient of variation was 0.7–3.3% across all cells. Also confirmed glide's
linux-x64-gnu native binary loads and reports 2.5.2.

Cross-engine key parity (needs a JDK 21 + the Java classpath):

# Dumps Java's KeyGenerator output and diffs it against the Node generator.
# See docs/BENCHMARKS_NODE.md § Cross-Engine Parity.

Known gaps

Plumbed and reviewed, but not exercised by a test:

• Cluster mode — GlideClusterClient / Redis.Cluster are wired from
  mode: cluster, but no cluster integration test exists yet.
• Auth and TLS — config is threaded through to every driver
  (credentials/username+password, useTLS/tls), untested end to end.
• benchmark-node CI job — YAML validates and mirrors benchmark-ruby, but
  the workflow is workflow_dispatch and has not been run.

Happy to close cluster + auth in this PR if you'd prefer them in before merge.

Notes for the reviewer

• Expect a conflict with Add Python benchmark engine (async valkey-glide, redis-py, valkey-py) #24 (Python engine) on Makefile,
  scripts/run_benchmark_matrix.py, scripts/generate_graphs.py,
  .github/workflows/benchmark.yml, and docs/ADDING_LANGUAGE.md. All changes
  here are additive; I'll rebase once Add Python benchmark engine (async valkey-glide, redis-py, valkey-py) #24 lands. This branch also carries the
  same docs/ADDING_LANGUAGE.md HDR-range fix (3600000000 → 600000000) that
  Add Python benchmark engine (async valkey-glide, redis-py, valkey-py) #24 makes, since it is a real correctness bug in the guide.
• config-editor's driver list was Java-only. I added Node's three ids;
  Ruby, C#, and Python are still missing from it. Out of scope here.
• The report's delta chart is blank for this matrix — pre-existing, filed as
  Delta charts render blank for any sweep without a spring-data-valkey-glide series #26. Not caused by this change.
• On the numbers: the sweep shows glide ~2× behind ioredis at 1 connection
  (10.3k vs 21.8k RPS), narrowing to ~18% at 16. I would not read that as a
  driver verdict — glide's Node client routes through a Rust core over a socket,
  and this workload holds one in-flight request per connection, which is where
  that architecture looks worst. A pipeline_depth sweep is the fair follow-up.
  docs/BENCHMARKS_NODE.md records the measured single-core ceiling: throughput
  plateaus ~43k RPS past 4 connections, and at pipeline_depth=16 the process
  pins 99% of one core at ~72k RPS — past that the engine, not the driver, is the
  limit.