Fix: keep recording folders responsive while metadata images load

[hotzenplotz5]

Nachgewiesene Ursache

Der Regressionstest auf dem realen VDR hat zwei voneinander unabhängige Blockaden gezeigt:

1. Personen- und Galeriebild-Endpunkte lösten für dasselbe EPG-Ereignis die TVScraper-Metadaten wiederholt synchron über SuiteBridge/SVDRP auf.
2. SimpleHttpListener akzeptierte Verbindungen seriell und schrieb auch große image/*-Antworten vollständig, bevor die nächste Verbindung angenommen wurde. Eine langsame Mobilverbindung beziehungsweise ein noch nicht lesender Bild-Client konnte dadurch einen nachfolgenden Aufnahmeordner-Request blockieren. Der direkte lokale Ordneraufruf blieb dabei gesund (HTTP 200, rund 85 ms), während die Browseroberfläche weiterhin bei „Lade Aufnahmeordner …“ stand.

Änderung

META-Auflösung

• begrenzter, thread-sicherer META-Antwortcache im typisierten SuiteBridge-Transport
• Schlüssel: channelId + eventId
• maximal 128 Einträge
• TTL: 5 Minuten
• ausschließlich erfolgreiche 250-Antworten werden gespeichert
• LRU-artige Verdrängung über Zugriffsequenz

HTTP-Auslieferung

• Controller, ApiRouter, SQLite und Backend-Adapter bleiben vollständig seriell auf dem Listener-Thread
• nur bereits fertig erzeugte image/*-Antworten werden an einen begrenzten Writer-Pool übergeben
• vier Writer-Threads, höchstens 16 wartende Bildantworten
• API-, JSON- und andere Nicht-Bild-Antworten behalten den bisherigen seriellen Pfad
• bei ausgelasteter Bildwarteschlange wird fail-closed eine kleine 503-Antwort geliefert, statt API-Aufrufe zu blockieren
• keine Änderung am Recording-Frontend und kein Timeout-Workaround

Reproduzierender Regressionstest

test_simple_http_listener_image_write_isolation.cpp erzeugt eine 16-MB-Bildantwort an einen Client, der die Antwort nicht liest, und fordert parallel den Aufnahmeordner Control an.

• gegen den bisherigen seriellen Listener: reproduzierbarer Timeout/fehlende HTTP-Antwort
• mit diesem Fix: Ordnerantwort HTTP 200 innerhalb von 1,2 Sekunden
• der bestehende Test für unvollständige beziehungsweise stockende Requests bleibt grün

Weitere Tests

• Cache-Treffer, Schlüsseltrennung, Fehlerausschluss, Verdrängung, Ablauf und deaktivierter Cache
• wiederholter identischer META-Aufruf erzeugt keine zweite Backend-Verbindung
• korrigiertes Linkziel test-epg-cache-artwork-json
• neuer Parallelitätsfall ist in test-ci-fast und test-vdr registriert

Der Personen-Feature-Branch bleibt weiterhin unverändert auf main. Dieser PR enthält ausschließlich den Regression-Fix und wird erst nach erneutem realen Mobiltest gemergt.

[hotzenplotz5]

CI-Abnahme nach der Link-Korrektur vollständig erfolgreich:

• docs-check: success
• make-test-audit: success
• frontend-regression-test: success
• fast-regression-test: success
• production daemon build: success
• packaging/install staging: success

Der erste Lauf hatte ausschließlich das bereits seit der EPG-Metadatenintegration unvollständige Link-Target test-epg-cache-artwork-json offengelegt. Die fehlenden Quellen EpgScraperMetadataResolverRegistry.cpp und EpgScraperMetadataPublicJsonSerializer.cpp sind jetzt im Testziel enthalten. Die neuen Cache- und META-Transporttests waren bereits im ersten Lauf erfolgreich.

[hotzenplotz5]

Closing as a stale mixed fix. The user-visible recording-folder blocking regression is covered on current main by the bounded image-write isolation path and its regression test. The separate transport-level META reply cache from this old branch was not retained as a current contract; today's EPG/cache architecture has moved on substantially. If repeated META lookups are still measurable on current main, that should be reproduced and handled as a fresh focused performance issue rather than merging this historical branch.