feat(search): honest has-preview prop and thumbnails relationship

[dschmidt]

Makes preview availability honest instead of a blanket mimetype match, and bases the driveItem thumbnails on it.

• Split the preview types into unconditional ones and those that carry their preview inside the file + HasPreview as the single source of truth (unconditional types follow from the mimetype, an audio cover depends on what the index saw). Both live in services/webdav/pkg/thumbnail now, where webdav owns the type list since Push based thumbnailer architecture #3397.
• Index the embedded cover: its dimensions and the type it is in, as oc.preview (preferring the front cover).
• The thumbnail of a cover is written in the cover's own type: webdav reads oc.preview.contentType when it stats the file, so the output type is settled before the cache key is built and a png cover stays a png. Nothing is derived from the image bytes, and the cache keeps its interface.
• No indexed cover, no preview. Without dimensions and type nothing can say what the thumbnail would be, so webdav answers 404 instead of extracting and guessing a format. The type mapping no longer pins audio to jpeg.
• Honest oc:has-preview for audio in search results (new preview field on the search message entity).
• Graph driveItem thumbnails ($expand=thumbnails) are gated on HasPreview and gain a source thumbnail requested at the original size. No thumbnail carries dimensions: the served size snaps to the configured resolution set, not knowable at listing time.

Stacked on #3332, which is what closes the gap this PR used to carry: the preview metadata and the rendered preview now come from the same extraction, so they cannot describe different pictures. What is indexed is what gets rendered.

Removing a cover does not clear an already indexed oc.preview yet. The stale facet cleanup in #3682 only covers the libre.graph. prefix, so whichever of the two merges last has to add oc.preview. to its stale check.

Follow-ups (kept out to stay focused): consolidate the shared-view thumbnail blocks via a generic odata expand-set, and switch reva propfind has-preview to thumbnail.HasPreview.

Note

Even once this PR and #3211 (graph search query endpoint) are both merged, hits from POST /graph/v1beta1/search/query still won't carry thumbnails: the $expand=thumbnails wiring for search hits builds on both PRs and currently only exists on the consolidation branch (dschmidt/opencloud@feat/graph-search-full-2, commit 0d94199a: searchEntityThumbnailSet in searchquery.go, preview presence via thumbnail.HasPreviewForMimeType + indexed oc.preview/image-facet dimensions). It needs a follow-up PR once both are in.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 50 complexity

Metric	Results
Complexity	50

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[butonic]

I would prefer a single oc.preview property with 200x300 as the dimension. While we do cache the properties in nats, I think splitting by x is more efficient.

[dschmidt]

I'm not the biggest fan tbh.

Would need concatenation on the indexing site and parsing on the consuming side, while making querying for it more awkward and require special handling.
I could imagine for my music server it could be nice for some views to query only files with specific (minimal) preview sizes e.g.

If you insist, we can do it.. but I'd prefer not to

[butonic]

Hm ...

I need the availability and dimensions of embedded previews at index time (#3210).

🤔

You mean you need them to be created when indexing (after postprocessing), so they are available during dirlistings?

[dschmidt]

I need the availability and dimensions of embedded previews at index time (#3210).

You mean you need them to be created when indexing (after postprocessing), so they are available during dirlistings?

Basically, yes - I need the dimensions in ArbitraryMetadata during listings and in the index during search, so I can fill the thumbnails relationship.
It's basically the same as all the other extracted metadata like audio artists, geo data in images, etc.
This was the original motivation to implement the extraction in Tika, so it's completely anologous to the other metadata extraction, because that seemed like a completely natural fit.
The only downside of doing it like this is, that previews for files out of the EmbeddedPreviewMimeTypes group become available only when they have been indexed.

[dschmidt]

This can be solved more elegantly with the approach in #3332 but this is good enough for an interim step