feat(cache): use binary envelopes for package cache writes

[zharinov]

Changes

Package cache writes store binary envelopes instead of JSON-wrapped base64 strings.

• PackageCacheBase owns set(). It encodes the value into an envelope and passes the bytes to the backend's writeRaw().
• Each backend stores opaque bytes and handles TTL with its native mechanism:
  • Redis writes the bytes with EX.
  • SQLite writes the bytes to its data blob and keeps its expiry column.
  • File cache writes the bytes with cacache and stores expiry in the index metadata.
• A non-positive TTL deletes the entry instead of writing a value that is already expired.
• File-cache cleanup reads expiry from cacache index metadata. It no longer opens and parses every content file, and the in-memory expiry map is gone.
• All backends share one codec, so SQLite payloads now use brotli quality 8 like the others.

Reads still fall back to the legacy JSON-wrapper decoder, so existing entries keep working. legacy.ts stays until pre-envelope entries age out.

Notes:

• New writes overwrite legacy entries in place. Keys are unchanged.
• The first file-cache cleanup after upgrading removes legacy entries that have no expiry metadata. Later runs rewrite them as envelopes.
• Smaller payloads: the JSON wrapper and base64 layer are gone.

Context

Please select one of the following:

• This closes an existing Issue, Closes: #
• This doesn't close an Issue, but I accept the risk that this PR may be closed if maintainers disagree with its opening or implementation

AI assistance disclosure

Did you use AI tools to create any part of this pull request?

Please select one option and, if yes, briefly describe how AI was used (e.g., code, tests, docs) and which tool(s) you used.

• No — I did not use AI for this contribution.
• Yes — minimal assistance (e.g., IDE autocomplete, small code completions, grammar fixes).
• Yes — substantive assistance (AI-generated non-trivial portions of code, tests, or documentation).
• Yes — other (please describe):

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests, but ran on a real repository, or
• Both unit tests + ran on a real repository

The public repository: N/A — local Redis smoke tests covered single-node Redis and a 3-node Redis cluster.

[zharinov]

This is smooth for the SQLite and Redis backends. For the cacache, it's cache purge + cold start after update.

[zharinov]

Just updated cacache case to migrate on read. If read migrates 1/10 items, 9/10 are still purged, and second run will be a cold start for sharded scenarios. Do we regard this as acceptable?