Add Redis-backed response caching to the API

[bpepple]

Description

Adds Redis-backed response caching to the read-only DRF API to reduce DB load on the heavier viewsets (Issue, Series, etc.), with automatic invalidation on writes — no manual cache-busting to maintain.

Two schemes, matched to endpoint shape:

• Detail (retrieve, and detail-scoped actions like issue_list) cache under a key derived from the object's pk + modified timestamp. A write changes modified, which changes the key, so old entries are simply orphaned and expire via TTL (24h) — no explicit delete needed.
• List (list, plus series_list) cache under a per-model cache-generation counter in Redis, bumped by the existing modified-cascade signals whenever that model (or Issue, for the Series list's embedded num_issues) changes.

Applied to the 9 public catalog viewsets (Arc, Character, Creator, Imprint, Issue, Publisher, Series, Team, Universe). Deliberately not applied to Collection/PullList/WishList/ReadingList — those are user-scoped (get_queryset filters by request.user), and a shared list-cache key would leak one user's data to another; that's left uncached for now rather than bolted on in this PR.

Also fixes a gap where Credits changes never bumped the parent Issue's modified timestamp (so a credit could change without invalidating the issue's cached/conditional-request state), and adds the missing cache-invalidation signal wiring for Publisher/Imprint/Universe, which previously had none.

DETAIL_CACHE_TTL/LIST_CACHE_TTL are both single constants in api/cache.py — starting at 24h/2min, to be tuned against production Redis memory usage.

Follow-up fixes

A review of the caching design surfaced a few gaps, fixed here:

• Staleness: Arc/Character/Team issue_list and Series retrieve were cached under the parent object's own modified timestamp, which doesn't change on every edit that affects the cached payload (a plain issue field edit doesn't bump the parent Arc/Character/Team; a Publisher/Imprint rename doesn't bump the owning Series). Both now also key off the dependent model's cache-generation counter.
• Race: CreditSerializer.create() bumped Issue.modified before attaching credit roles, so a request landing in that window could cache an issue with an empty role list under a key nothing would later invalidate. A new m2m_changed signal on Credits.role bumps again once roles actually land.
• Query cost: the cheap (pk, modified) lookup used for conditional requests and cache-key computation was still carrying the retrieve queryset's annotate() aggregates into an extra JOIN + GROUP BY on every request (cache hits included) for Issue/Series. Fixed via a leaner get_modified_queryset().

Further fixes and cleanup

A second review pass caught a few more gaps in the same class as above, plus some efficiency/maintainability polish:

• More staleness gaps: Issue retrieve embeds Series/Publisher/Imprint names, and Imprint/Universe retrieve embed their Publisher's name — none of which cascaded a modified bump onto the cached object. Arc/Character/Team issue_list also nests each issue's Series name without depending on it. All now mix in the relevant model's version counter, same pattern already used for Series. (Character/Team retrieve still omit Creator/Universe on purpose — those are edited/added far more often than Publisher/Imprint, so tracking them would tank the cache hit rate for comparatively little benefit; documented inline.)
• PublisherViewSet.series_list existence check: skipped get_object() (and therefore the existence/permission check) entirely on a cache hit — a deleted publisher's cached series list kept returning 200 instead of 404 until the 2min list-cache TTL caught up.
• Cleanup: ModelLabel is now a StrEnum (a typo'd label is caught by type checking instead of silently creating a dead, never-invalidated counter); list_cache_key()/detail_cache_key() batch dependent-label lookups into one Redis get_many() instead of one get() per label; get_model_version()'s cold-start path trimmed from 3 Redis round trips to 2; the 16 near-identical per-model post_save/post_delete connections in comicsdb/apps.py collapsed into a table-driven loop.
• audit_response_cache management command: a one-off audit of the response cache's Redis footprint (key counts/estimated memory per category, hit rate, eviction stats), meant to be run against production after this deploys to inform whether DETAIL_CACHE_TTL/LIST_CACHE_TTL need tuning rather than guessing.