Fix IIIF Level 0 thumbnail resolution

[ewlarson]

Summary

• Preserve the stable OGM resource thumbnail endpoint while resolving IIIF Image API info.json documents according to their advertised capabilities.
• Select an advertised static rendition for Level 0 services instead of generating an unsupported !800,800 request.
• Tighten IIIF Presentation manifest detection so files such as dataset_manifest.json are not fetched as images.
• Apply the resolved source consistently across worker fetching, hashing, caching, cache clearing, and the no-cache endpoint.
• Add regression coverage for the affected UNR resource and the complete info.json → rendition → image-cache worker path.

Root cause

The affected UNR records expose static IIIF Image API Level 0 services. OGM rewrote those sources to /full/!800,800/0/default.jpg, but Level 0 only guarantees its advertised sizes; the generated request returned 403 even though a valid rendition existed. Separately, the broad manifest heuristic classified dataset_manifest.json as a IIIF Presentation manifest, causing JSON to be processed as image content.

Impact

After deployment, the existing meta.ui.thumbnail_url contract remains unchanged. An uncached request queues generation and returns the non-cacheable fallback while processing; subsequent requests redirect to the real cached thumbnail.

Validation

• 59 passed across focused service, worker, and endpoint tests
• ruff check passed for all changed files
• ruff format --check passed for all changed files
• git diff --check passed
• The exact selected UNR rendition /full/924,/0/default.jpg returns 200 OK with Content-Type: image/jpeg