Handle optional approved poster fields on MovieVault release-details responses

[helmerzNL]

MovieVault v2 POST /v2/release-details/resolve can now return the approved
catalog poster of the resolved release and box set as two optional
response-level fields. Until DiscVault handles them, the MovieVault side keeps
the feature behind release_details_poster_enabled, which defaults to false.

Upstream: Flux76HQ/MovieVault-v2#111 (version 0.10.76).

Why this is small

The object is the distribution-4 poster reference reused unchanged. If
DiscVault already parses and caches posters from the bulk distribution sync, the
same type, the same download path, and the same cache apply here. No second
model, no new endpoint, no new auth.

New response shape

Both fields are omitted entirely when there is no approved poster, so payload
bytes are unchanged for releases without one.

{
  "status": "canonical_hit",        // or "external_hit"
  "verificationStatus": "canonical",
  "film": { },
  "release": { },
  "boxSet": { },                    // optional, already existed
  "poster": {                       // NEW, optional
    "assetId": "0f3c1a2b-....",
    "assetType": "front_cover",     // always front_cover for a poster
    "attestation": "original",      // original | licensed
    "license": "cc0-1.0",           // cc0-1.0 | cc-by-4.0 | cc-by-sa-4.0
    "thumbnail": {
      "path": "/v2/assets/0f3c1a2b-..../thumbnail",
      "checksum": "<sha256 hex, 64 chars>"
    },
    "display": {
      "path": "/v2/assets/0f3c1a2b-..../display",
      "checksum": "<sha256 hex, 64 chars>"
    }
  },
  "boxSetPoster": { }               // NEW, optional, same shape
}

Work

1. Open up the response parser

If the release-details response is validated with a closed DTO or a schema with
additionalProperties: false, it will now reject payloads that carry a poster.
That has to be relaxed before the MovieVault flag can be turned on anywhere.

Reuse the existing distribution-4 poster type verbatim rather than declaring a
second one.

2. Two behavioural rules that are easy to get wrong

• An external_hit may also carry a poster. Do not filter on
  verificationStatus. That field describes the provenance of the technical
  data; the poster is a moderated MovieVault catalog poster by definition and is
  resolved from the canonical entity the requested barcode points at, never from
  the plugin result.
• boxSetPoster never appears without boxSet. Reading it only when
  boxSet is present is already correct.

3. Download

path is relative; prefix it with the configured MovieVault base URL. Anonymous
GET, no auth header, no cookie. Same route as the bulk-sync poster path.

• Verify the downloaded bytes against checksum (sha256, also returned as
  X-Content-SHA256). On mismatch, discard and do not display.
• Honour ETag / If-None-Match (304).
• The asset route is anonymously rate limited. Handle 429 with Retry-After;
  this is realistic when resolving many barcodes in a row.
• thumbnail is for lists, display for detail views. Do not fetch display
  when it is not shown.

4. Cache invalidation

Response headers on the bytes are public, max-age=31536000, immutable, which is
safe because the bytes behind an assetId never change.

The link from a release to a poster is not immutable. Cache bytes keyed by
assetId/checksum, but take the release -> poster association only from a fresh
response. After a takedown or replacement the old assetId disappears from
future responses and the asset route stops serving it. A locally stored assetId
must therefore be overwritable with null on a later lookup or sync, otherwise
DiscVault keeps showing a withdrawn poster.

Acceptance criteria

• A release-details response without poster fields parses exactly as
  before; no behaviour or byte-level change for existing installs.
• A response with poster parses, and the poster renders in the release
  view.
• A response with poster and boxSetPoster parses; the box-set poster is
  used for the box set, not for the member release.
• An external_hit response with a poster renders the poster.
• A checksum mismatch on download discards the image instead of displaying it.
• A 429 from the asset route is retried according to Retry-After and does
  not fail the surrounding barcode lookup.
• A previously cached poster is dropped when a later response omits poster.
• Verified end to end against a MovieVault instance with
  release_details_poster_enabled = true.

Rollout order

1. Land the DiscVault side with the fixture tests above.
2. Enable release_details_poster_enabled on a MovieVault test instance and run
   a real barcode lookup.
3. Only then enable it in production.

[helmerzNL]

Scope-update: hergebruik de bestaande distribution-4 posterconsumer

Bij het opnieuw nalopen van de serverkant blijkt dit issue kleiner dan hierboven
beschreven. DiscVault heeft de posterlogica al.

Het object is letterlijk identiek. De server hergebruikt
PublicPosterReference uit distribution/models.py ongewijzigd voor de
release-details response. Zelfde velden (assetId, assetType, attestation,
license, thumbnail{path,checksum}, display{path,checksum}), zelfde
padvorm ^/v2/assets/[0-9a-f-]+/(thumbnail|display)$ als
distribution-v4.schema.json, zelfde asset-route, zelfde caching- en
checksum-semantiek.

De parser, downloader, SHA-256-verificatie en cache die al voor
distribution-4 gebouwd en geaccepteerd zijn, kunnen dus 1 op 1 worden
aangeroepen. Geen tweede implementatie schrijven.

Wat er dan nog echt moet gebeuren:

1. Het response-DTO van POST /v2/release-details/resolve openzetten voor de
   twee optionele sleutels poster en boxSetPoster. Als dat DTO gesloten is
   (onbekende sleutel = fout) is dit de enige harde blocker.
2. De bestaande v4-posterparser op die twee sleutels aanroepen.
3. Niet filteren op verificationStatus. Ook bij external_hit is de poster
   canoniek goedgekeurd; verificationStatus beschrijft alleen de herkomst van
   de technische data.
4. boxSetPoster alleen tonen wanneer de response ook een boxSet bevat.
5. Cachen op assetId, maar de koppeling release -> poster elke keer opnieuw
   uit de verse response lezen. Bij een takedown laat de server het veld
   direct weg; een gecachte koppeling zou een ingetrokken poster blijven tonen.
6. Geen capability-probe bouwen. public_summary() wordt niet over HTTP
   geserveerd; afwezigheid van de sleutels is normaal en betekent niets meer dan
   "geen goedgekeurde poster of feature staat uit".

Serverstatus. De feature is gemerged (Flux76HQ/MovieVault-v2#111) en de
feature-flag RELEASE_DETAILS_POSTER_ENABLED is nu ook echt aan te zetten in
een deployment (Flux76HQ/MovieVault-v2#116; hij zat eerder alleen in het
settings-model en bereikte de container nooit). De flag blijft false tot dit
issue rond is.