fix(metadata): stop alerting on inline unwired filters at warmup

[soyuka]

Q	A
Branch?	4.4
Bug fix?	yes
New feature?	no
Deprecations?	no
Issues	Fixes #7361
License	MIT
Doc PR	n/a

Supersedes #8408 by @alexisLefebvre, whose commit is cherry-picked here (the diagnosis and the fix are his).

What

An inline filter instance passed to a QueryParameter is never wired with a ManagerRegistry, unlike a filter resolved as a service through the filter locator. Reading its legacy description during metadata build therefore throws, gets caught, and is logged at alert — one identical ALERT ManagerRegistry must be initialized before accessing it. line per parameter on every cache:clear. Filtering itself is unaffected: ParameterExtension wires the registry at query time.

That failure is expected on this path, so it is now logged at debug. A RuntimeException from any other cause — a filter that is not ManagerRegistryAware, or one that is already wired — still logs at alert.

Why this shape

The condition is knowable before calling getLegacyFilterMetadata(), so an early return looked tempting. It is not safe: a userland filter extending AbstractFilter (hence ManagerRegistryAwareInterface) may override getDescription() with something that needs no registry, and skipping would silently drop its description. Downgrading inside the catch only changes the level of a message on a path that already failed, so nothing that works today changes.

Note this does not go away on its own for the surviving filters: on main, DateFilter is standalone but still use ManagerRegistryAwareTrait, and DateFilterTrait::getDescription() still calls getClassMetadata(). Users migrated to the canonical filters (ExactFilter, SortFilter, ComparisonFilter, …) are already unaffected — BackwardCompatibleFilterDescriptionTrait returns an empty description and never touches Doctrine.

Tests

src/Doctrine/Orm/Tests/Metadata/Resource/UnwiredLegacyFilterParameterTest.php drives a real new QueryParameter(filter: new DateFilter()) — the exact declaration from the issue — and asserts debug rather than alert, plus a second case pinning that an unrelated failure still alerts. It lives in doctrine-orm rather than metadata because api-platform/metadata does not depend on api-platform/doctrine-common, so a fixture using ManagerRegistryAwareTrait would make the split package's suite fatal.