fix: treat Redis GET abort/timeout as cache miss (reduce log spam)

[JannikZed]

Closes #57.

Problem

On fresh deployments (often with a new keyPrefix) the cache is effectively empty and the first requests are expected to miss.
However, we also observed noisy console.error logs in production when Redis GET is aborted due to the handler's own timeout (AbortSignal.timeout(getTimeoutMs)).
This is an expected fallback behavior of this cache handler (it prefers rendering over blocking on Redis), but it previously produced error-level logs via redisErrorHandler().

What this PR changes

• Treat Redis GET abort/timeout as a cache miss: if the redis client rejects with AbortError / ABORT_ERR, we return null without passing the error into redisErrorHandler().
• All other redis errors still go through redisErrorHandler() and are logged as console.error.

Why this does not hide real errors

• A real cache miss is a successful Redis response of null (no exception) and is already handled.
• The only suppressed case is the specific abort error caused by our own timeout signal.
• Connection/auth/protocol/etc. errors still throw and are still logged.

Tests

• Added a unit test that simulates an aborted GET and asserts:
  • RedisStringsHandler.get() returns null
  • console.error is not called

Notes / follow-ups

If we want observability for timeout frequency without log floods, we can add an optional/sampled timeout logger or metric counter in a follow-up PR.

[github-actions]

Coverage Report

Coverage after merging fix/redis-timeout-as-cache-miss into main will be:

	Hit/ Total	Coverage
🌿 Branches	33 / 241	13.69% 😕
🔢 Functions	10 / 78	12.82% 😕
📝 Lines	56 / 383	14.62% 😕