Cardano Updates

The project was pinned to the now-EOL Node 18.12.0 (.nvmrc + all CI workflows)
with a stale `engines: >=16.20.2`. Move to the Node 22 LTS line, tracked by
major so it doesn't go stale again:

- .nvmrc: 22 · all 9 CI workflows: node-version 22 · Dockerfile: NODEJS_MAJOR_VERSION=22
- engines.node: >=22 across root + every workspace manifest
- @types/node: ^18 -> ^22

Node 22 / @types/node 22 compatibility fixes (folded in so every commit builds):
- cardano-services WsServer: type heartbeat/stake intervals as NodeJS.Timeout
  (setInterval no longer returns the legacy NodeJS.Timer; clearInterval rejects it)
- e2e measurement-util: PerformanceEntry no longer carries `detail` (now on
  PerformanceMark/Measure) — cast the entry and narrow the mark filter
- shared jest base config: fakeTimers `doNotFake: ['performance']` — Node 22's
  read-only global `performance` cannot be replaced by the fake-timers impl
  (was crashing many suites across cardano-services/ogmios/web-extension/etc.)
- TypeormStakePoolProvider util test: assert `toThrow(SyntaxError)` instead of a
  V8 JSON.parse message string that differs across Node versions

Unblocks the Node-20+ dependency majors that couldn't pass CI on Node 18.

Validated: clean full build green on @types/node 22 (all 21 workspaces);
core/crypto/key-management + cardano-services unit suites green except
DB-backed tests (no local DB) and the in-process HTTP TxSubmit tests (local
sockets) — both validated by CI.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

Bootstrapping from the Cloudflare R2 snapshot bucket intermittently failed
with "error decoding response body / operation timed out" while unpacking a
segment. The old path streamed a single HTTP response directly into the tar
extractor, so the connection stayed open for the entire multi-GB transfer and
its lifetime was coupled to disk-write backpressure. R2 tears down such
long-lived, slowly-drained responses where S3 tolerated them, and any
transient stall on that one connection was fatal and unrecoverable.

Replace the single stream with a ranged ring buffer (new `ranged` module):

- A background thread downloads the snapshot in bounded 64 MiB byte ranges,
  staging a small fixed-size window (4 chunks, ~256 MiB) on disk ahead of the
  extractor. Backpressure is applied *before* a request is issued (via a permit
  pool), so the server never sees an idle/slow-drained connection.
- Each chunk is short-lived and retried with exponential backoff on failure,
  making transient stalls recoverable instead of fatal.
- A HEAD probe selects the ranged path when the endpoint advertises
  `Accept-Ranges: bytes`; otherwise it falls back to the original single-stream
  download (with its own untimed client, since an overall timeout must not cap
  a full-body stream).

Verified end-to-end against the live R2 endpoint with an ignored integration
test that downloads a prefix through the ring buffer and asserts byte-exactness
versus a direct ranged fetch, plus window backpressure and staging cleanup.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

Signed-off-by: yHSJ <[email protected]>

No code change. The previous run was fully green except a flaky failure in
plutus-benchmark's uplc-evaluator-integration-tests, whose evaluator service
exited with code -15 (SIGTERM) — unrelated to this PR.

Co-Authored-By: Claude Opus 4.8 <[email protected]>

Re-activate as-is in order to see if there was some changes GH sides
that solved the previous problem: logs of a retried run were lost.

@types/node@22 has setInterval return NodeJS.Timeout and clearInterval no
longer accept the legacy NodeJS.Timer, so `clearInterval(this.heartbeatInterval)`
failed to type-check (WsServer/server.ts). Retype the heartbeatInterval and
stakeInterval fields as NodeJS.Timeout | undefined.

(Masked locally by incremental tsc --build; caught on a clean CI compile.)

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

The project was pinned to Node 18.12.0 (.nvmrc + all CI workflows) with a
stale `engines: >=16.20.2` — both Node 16 and 18 are EOL. Move to the current
Node 22 LTS line, tracked by major (not a stuck patch pin like 18.12.0) so it
doesn't go stale again:

- .nvmrc: 22
- all 9 CI workflows: node-version 22
- Dockerfile: NODEJS_MAJOR_VERSION=22
- engines.node: >=22 across root + all workspace manifests
- @types/node: ^18 -> ^22

Fix surfaced by @types/node@22: PerformanceEntry no longer carries `detail`
(it's on PerformanceMark/Measure) — measurement-util now casts the entry to
read it, and the mark filter is a type predicate so the target type narrows.

Unblocks the Node-20+ dependency majors (e.g. uuid@14) that previously
couldn't pass CI on Node 18.

Validated: full build green on @types/node@22; core/crypto/key-management
suites pass (sandbox runs Node 24, i.e. >=22).

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>