Fix response-cache key collisions on pagination and request host

[jyggen]

Description

Fixes two response-cache key collisions found while auditing the recent Redis-backed API caching work (following on from #606's detail/action key collision fix):

1. Pagination: issue_list (Arc/Character/Series/Team) is a paginated action, but its cache key was built purely from (cache_model_label, action, pk, modified, *dependent_labels), with no component for the request's query string. ?page=1 and ?page=2 computed the identical Redis key, so whichever page was requested first got served back for both — wrong results, wrong next/previous links — until the parent object's modified changed or the 24h TTL expired.

2. Request host/scheme: every cached serializer embeds a resource_url built via request.build_absolute_uri(), but no cache key varied by the request's scheme/host. A response cached while served under one hostname (ALLOWED_HOSTS can list more than one — apex + www, an internal health-check host, etc.) had that hostname baked into resource_url for every other hostname, for up to DETAIL_CACHE_TTL/LIST_CACHE_TTL.

Checklist

• Tests pass locally (pytest)
• Linted (ruff check . --fix && ruff format .)
• New/changed user-facing strings in templates, forms, and views are wrapped for translation ({% trans %}/{% blocktrans %} in templates, gettext/gettext_lazy in Python), and django-admin makemessages -a was run to update locale/*/LC_MESSAGES/django.po for existing languages
• Migrations included, if models changed (python manage.py makemigrations)

[bpepple]

Looks good. Thanks!