File Link: feed the search index from the resolved fileid, not the cached path

[Rikdekker]

Follow-up to #73 (observation 1 from @CedricWagner).

Problem

A filelink value is stored as <fileid>:<path>. The fileid is canonical and resolves to the live name/path at render time, so rename/move already display correctly. But the <path> part is a display cache that is not refreshed when the target is renamed or moved.

This is cosmetic for the UI (we resolve from the fileid there), but it does matter for text-based search: if the search index is fed from the stored path string, a query against the path can return stale results after a rename/move.

Why not event-driven path rewriting

The original design in #73 deliberately rejected rewriting stored values on file move/rename events as too fragile (and there is no usable index to find referencing rows cheaply — it would be a leading-wildcard LIKE over metavox_file_gf_meta). We do not want to go there.

Proposed fix

Resolve filelink values to their current name/path via FileReferenceService::resolveMany() at index time, and index that instead of the cached path baked into the stored value. The stored value stays untouched; only what we feed the search index changes.

• lib/Search/MetadataSearchProvider.php / lib/Service/SearchIndexService.php — resolve filelink tokens to live name/path before indexing.
• Unresolvable (deleted) ids: index nothing for the path component, or fall back to the cached path — decide during implementation.

Acceptance

• Renaming/moving a linked target makes search match the new name/path on next index pass without rewriting any stored metavox_file_gf_meta values.
• No per-delete or per-move scan over metavox_file_gf_meta.