Cache public CSV responses (first consumer of the API cache)

[bencap]

Context

First consumer of the API cache (depends on the cache infrastructure, VariantEffect/mavedb-deployment#32). This issue delivers the reusable API-side cache module and applies it to the scores/counts CSV hot path so repeat public requests hit cache instead of rebuilding from the DB.

Part of the effort to make /scores & /counts safe to reopen to AI agents.

Scope — reusable cache module

• A small cache abstraction over the API cache Redis: namespaced keys, TTL, fail-open get/set (cache unreachable ⇒ compute normally, never error), per-entry size cap.
• Documented usage example so future hot paths can reuse it.

Scope — cache public CSV responses

• Cache rendered CSV bytes keyed by (urn, namespaces, start, limit, drop_na_columns, include_custom_columns, include_post_mapped_hgvs).
• Public score sets only; still run assert_permission per request — never cache or serve private data.
• TTL + per-entry size cap (skip caching very large CSVs).
• Invalidate on (re)publish / score-set data change.
• Define interaction with streaming (Stream /scores & /counts CSV responses (no row cap) #770): cache the assembled body for cacheable (public + within size cap) requests; stream-passthrough (no cache) otherwise — so streaming and caching coexist.

Acceptance criteria

• Repeat public requests served from cache (hit metric/log); private never cached.
• Invalidation on publish verified.
• Cache memory stays bounded (LFU + size cap); cache outage is fail-open (requests still succeed).

Dependencies

• Depends on VariantEffect/mavedb-deployment#32 (API cache infrastructure).
• Complements Stream /scores & /counts CSV responses (no row cap) #770 (streaming).