feat(cache): key cache entries by configured vary headers - #4915

Summary

• Improves cache efficiency when the Vary header is in use.
• Until now, options.vary only affected the response headers. With this PR, it also contributes to the cache key.
• This is also a follow-up to the v4.12.18 vulnerability fix (568c2ec), which made Vary-bearing responses uncacheable. The change preserves that fix while letting users opt back into caching where it's safe.

Behavior changes

The behavior changes when options.vary is configured:

Because of this behavior change, requests that were previously (unintentionally) sharing the same entry under options.vary are now split per header value, which can lower the hit rate. That said, this aligns with the intended semantics of Vary and should be a desirable change in virtually every deployment. On the flip side, paths that produced Vary-bearing responses — which were not cached at all after v4.12.18 — become cacheable again as long as their Vary is covered by options.vary, which raises the hit rate there.

Design note: interaction with options.keyGenerator

Users who already supply options.keyGenerator may already be folding the same request headers into the key themselves. With this change, those headers will be appended to the key a second time.

I considered skipping the options.vary-based key extension when options.keyGenerator is provided, but decided against it:

• If a user wrote their code assuming "configuring options.vary extends the cache key", silently skipping that extension would violate their assumption.
• A double append is a safe failure mode: it can only over-split variants — it cannot return the wrong response.

So when both are configured, options.vary still contributes to the cache key unconditionally.

The author should do the following, if applicable

• Add tests
• Run tests
• bun run format:fix && bun run lint:fix to format the code
• Add TSDoc/JSDoc to document the code