Fix tag-based manifest pulls 404ing while digest-based pulls succeed

[wussh]

Summary

• ManifestResponse.from_tag rejected requests based on the client Accept header, raising ManifestNotFound when the tag's manifest media type wasn't explicitly listed. from_manifest (the digest lookup path) never had this check, so the identical content served 200 by digest and 404 by tag — most visible for manifest-list/OCI-index tags whose media type clients often omit from Accept.
• Regression from Omit redirects to content-app #1974 (8479d527), which moved manifest serving from a content-app redirect (that ignored Accept) into the registry API view.
• from_tag now mirrors from_manifest: it always serves the tagged manifest, only rewriting schema v1 to the signed content type.

Fixes #2417

Test plan

• Reworked test_pull_content.py::test_api_performes_schema_conversion (previously asserted a 4xx with the comment "I don't understand what this is testing") into test_api_serves_tag_regardless_of_accept_header, which pulls the same manifest by tag and by digest with a narrow Accept header and asserts identical 200 responses.
• Reproduced end-to-end on the live domain-scoped, on-demand, follow-latest environment that originally reported Domain-scoped container registry: tag-based manifest fetch 404s, digest-based works (pulpcore 3.113.0 / pulp_container 2.28.0) #2417 (Domains enabled, S3-backed storage, pulpcore 3.113.0 / pulp_container 2.28.0). Pulled the exact live registry_api.py out of the running pulp-api pod, applied only the from_tag diff from this PR on top of it (no unrelated version drift), wrote it back into the running container, and reloaded gunicorn workers (no pod restart). Results:
  • Before patch: tag pull 404, digest pull 200 (matches the issue exactly).
  • After patch: tag pull 200, digest pull 200, tags/list 200, and the tag/digest response bodies are byte-identical.
  • Verified pod stayed healthy throughout, then reverted the pod back to the original unpatched image and re-confirmed the original 404 baseline — no lasting changes were left on the cluster.

[wussh]

Verified this fix end-to-end against the live cluster that originally hit #2417 (Domains + on-demand + follow-latest distribution, S3 storage, pulpcore 3.113.0 / pulp_container 2.28.0):

• Before: GET /v2/default/quay/prometheus/prometheus/manifests/latest → 404; the same manifest by digest → 200.
• After (applying only this PR's from_tag diff to the live registry_api.py, no unrelated changes, then reloading gunicorn workers): tag pull → 200, digest pull → 200, tags/list → 200, and the tag/digest response bodies are byte-identical.
• Cluster was left in its original (pre-fix) state afterward — no permanent changes.