Add optional thumbnails to graphics manifest (Issue #20)

[Richardpwe]

Each entry has file (required, path to image) and optionally resolution (object with width and height in pixels). Allowed image formats: PNG, JPG, GIF, webp.

Why resolution instead of ratio:
We use resolution (width × height) instead of a predefined ratio enum (e.g. 16by9, 9by16) so that UIs get actual pixel dimensions and can derive the aspect ratio when needed (e.g. width/height). Multiple thumbnails in different resolutions are supported directly, and the schema stays flexible without a fixed set of ratio strings.

[dvdeurse]

Path to the image file, relative to the manifest or absolute

In case it is absolute, shouldn't it be a URI then?

[Richardpwe]

Good point @dvdeurse.
To be more precise, I would phrase it as:

Reference to the image file, either: a relative path (resolved relative to the manifest), or an absolute URI (e.g. file://… or https://…).

If that sounds good to you, I’ll update the PR accordingly.

[nytamin]

nit-picking: should we name this property path instead?

[nytamin]

A possible thing to consider is if the Server API needs to be extended to support thumbnails in a meaningful way:
How a client/controller can retrieve thumbnails over the Server API, as I don't think it is aware of what URL a graphic is served from at the moment.

[jhobz]

A possible thing to consider is if the Server API needs to be extended to support thumbnails in a meaningful way: How a client/controller can retrieve thumbnails over the Server API, as I don't think it is aware of what URL a graphic is served from at the moment.

Seconding this. Some clients could greatly benefit from being able to get the thumbnail for a graphic from the server. I don't think it needs to be a requirement that blocks this PR though. I think the API endpoint could come separately.