[BUGFIX] Reset alreadyDisplayed news list between requests

[contemas-tschmidt]

Problem

ExcludeDisplayedNewsViewHelper and NewsRepository::findDemanded() track already-rendered news UIDs in $GLOBALS['EXT']['news']['alreadyDisplayed'] to support the excludeAlreadyDisplayedNews demand. This array is a plain PHP superglobal, not request-scoped state, and nothing in the extension ever clears it.

Under PHP-FPM (or any SAPI that reuses one PHP process across several HTTP requests) the array keeps every UID added by every request handled by that worker, for the worker's entire lifetime. The resulting NOT IN (...) condition in NewsRepository grows without bound, and on a site with a few thousand news records this reliably exhausts memory_limit with an "Allowed memory size exhausted" fatal error after enough requests land on the same worker - with a stack trace pointing at whatever allocation happened to be the last one to fail, which has nothing to do with the actual root cause. This made it very hard to track down in practice.

I couldn't find an existing issue describing this specific failure mode, so I'm opening this PR directly together with the fix.

Fix

Add a frontend middleware that resets the array at the start of every request. This keeps the intended per-page behaviour (no duplicate news within a single page) while removing the cross-request growth under FPM.

Testing

Reproduced the crash locally and in a staging environment with excludeAlreadyDisplayedNews enabled on a news list, confirmed repeated requests against the same long-lived worker process eventually crash without this fix, and confirmed the fix resolves it (many consecutive requests succeed cleanly with the middleware in place).

[contemas-tschmidt]

The CI run showed two unrelated failures:

• Rector flagged the fully-qualified class name in Configuration/RequestMiddlewares.php — fixed in the latest commit (use-import instead).
• The NewsTest::falMediaPreviewsAreReturned unit test error (FileReference::$originalFile must not be accessed before initialization) is unrelated to this change — it also fails against current main with composerInstallHighest (dependency drift on the "highest" TYPO3 core version resolved today), not something introduced by this PR.