feature: content app json listing

[TenSt]

📜 Checklist

• Commits are cleanly separated with meaningful messages (simple features and bug fixes should be squashed to one commit)
• A changelog entry or entries has been added for any significant changes
• Follows the Pulp policy on AI Usage
• User documentation and test coverage has been added

Description

This PR:

• Serves paginated JSON directory listings when the content app Accept prefers JSON
• Adds Distribution.content_handler_json() so plugins can customize that JSON
• Keeps HTML/binary responses for browsers and other non-JSON clients

Closes #7887

[dkliban]

Re-review (v2)

Both findings from the initial review have been addressed:

Resolved: list_directory_flat now uses DB-level pagination

Pagination is pushed to the database with path_qs[offset:offset+limit] and .count() for the total. Only the page's items are loaded into memory. The _content_relationships() date lookup is now filtered with .filter(content_id__in=content_ids). A new test asserts that LIMIT appears in the captured SQL. This addresses the O(N) memory concern.

Resolved: Cache keys now use normalized pagination params

make_key now computes a normalized {limit}:{offset} string for JSON requests (via the shared json_listing_pagination() function) and omits the query component entirely for HTML requests. Junk query params are ignored for both formats. Verified with our proving test — all 3 cache pollution scenarios now pass.

Remaining: CI lint failure

The v2 push has a lint failure on import sorting (ruff check --fix && ruff format should fix it). Tests are gated on lint so haven't run yet in CI.

[TenSt]

@dkliban thanks for the review!

1. I've added DB pagination to the list_directory_flat function.
2. Removed query string as a whole from the cache (for json requests only) - only limit and offset will be used.
3. Skipped it as file content has no special JSON shape, so the generic listing is the right default. There is test that covers this: test_json_vs_html_listing_and_artifact.