fix(selfhost): 3 Redis cache wrappers handle a connection failure 3 different ways, one recording no error signal at all

[JSONbored]

Context

src/selfhost/redis-token-cache.ts:22-27 has no try/catch around await redis.get(...) itself (only around the subsequent JSON.parse), so a Redis connection failure throws uncaught out of get() with no metric recorded. src/selfhost/redis-response-cache.ts:38-44 wraps the equivalent redis.get() call in try/catch, records a loopover_redis_gh_response_cache_total{result:"error"} metric, and re-throws. src/selfhost/redis-cache.ts:18-28 wraps its cache.get() call and fails open (return false) instead. Three modules implementing the identical "Redis-backed lookup" shape handle the same failure mode three different ways — one of which records zero observability signal.

Requirements

• Decide which failure-handling contract is correct for redis-token-cache.ts specifically (fail-open like redis-cache.ts, or throw-with-metric like redis-response-cache.ts) by checking what its actual callers expect today — do not assume, verify.
• Apply that contract consistently, at minimum recording a metric on failure (whichever direction is chosen) so this failure mode is never silently invisible.
• Do not change the other two files unless a genuine inconsistency in THEIR behavior is also found during this work.

Test Coverage Requirements

99%+ Codecov patch coverage on the changed error path; a regression test simulating a Redis connection failure and confirming the chosen behavior (metric recorded, and either a clean throw or a fail-open return, per the decision).

Deliverables

• redis-token-cache.ts's Redis failure path records an observability signal and behaves per a deliberate, verified decision.

Expected Outcome

A Redis outage affecting the token cache is no longer invisible to this codebase's own metrics.

Links & Resources

• src/selfhost/redis-token-cache.ts:22-27, redis-response-cache.ts:38-44, redis-cache.ts:18-28

[linear-code]

JSO-4373