fix: reject invalidation without Redis

[lan17]

Closes #98

Summary

Make explicit remote invalidation fail loudly when a DialCache instance has no configured Redis client.

• reject invalidateRemote() with a focused TypeError
• record the existing invalidation attempt and bounded error="invalidation" metric
• log through the existing safe logger boundary and preserve the original error
• keep local-only caching supported and preserve configured-Redis behavior
• document the Redis requirement in public TSDoc and the README

Root cause and behavior

invalidateRemote() validated futureBufferMs and then returned successfully when DialCacheConfig.redis was absent. That fulfilled promise could tell a mutation path that a watermark had advanced even though no Redis operation occurred.

The missing-client check now throws inside the existing invalidation failure path. Validation still runs first, observers remain fire-and-forget and isolated, and successful or failed configured-client calls follow the unchanged Redis path.

Compatibility

This intentionally changes only explicit remote maintenance calls on local-only instances. Applications that intentionally omit Redis should skip invalidateRemote(); normal local-only cache reads and writes remain supported.

Open batch-invalidation PR #114 is based on the same main commit. If it merges first, this branch must be rebased and extended so nonempty invalidateRemoteMany() calls receive the same failure and observability behavior while its documented empty-batch no-op is preserved.

Validation

Node.js 22.22.0:

• corepack pnpm check
  • typecheck passed
  • 407 unit tests passed with 97.10% statement coverage
  • ESM/CJS builds and declarations passed
  • packed-consumer tests passed
• corepack pnpm test:integration
  • 93 Redis 6.2, Valkey 8, and three-primary Redis 7 Cluster tests passed
• focused invalidation/local-only run: 63 tests passed
• git diff --check passed