Fix RedisCacheHandler SET TTL calculation

[tobiasvdorp]

Summary

Fixes a Redis cache write bug in RedisCacheHandler.set().
calculateLifespan() stores expireAt as epoch seconds, but the Redis TTL calculation compared it directly with Date.now() in milliseconds. That made the computed TTL <= 0, so writes with a TTL were skipped as already expired instead of being stored in Redis.
This changes the Redis TTL calculation to compare seconds with seconds, so SETEX receives a positive TTL again.

[gemini-code-assist]

Code Review

This pull request introduces a helper function redisTtlSecondsFromLifespan to correctly compute the remaining Redis EX TTL in seconds from lifespan parameters, fixing a bug where the previous formula (which mixed milliseconds and seconds) resulted in negative or zero TTL values and skipped writes. It also adds corresponding unit tests for this helper and the Redis cache handler. The reviewer recommends restoring real timers after using fake timers in the new test suite to prevent test flakiness.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Using vi.useFakeTimers() without restoring them can leak fake timers to subsequent tests in this file or other test files, leading to unexpected behavior or flakiness. Please ensure that real timers are restored after the tests in this block run.

  describe("TTL on set", () => {
    afterEach(() => {
      vi.useRealTimers();
    });

    test("should store entry with setex when defaultTTL is configured", async () => {