GenericFilter: URL condition parameters are parsed into UI components before it is known whether a component is needed

[fractal3000]

See #5623

GenericFilterUrlQueryParametersBinder used to build a full PropertyFilter component for every condition in the URL — with a data loader assignment, a generated value widget and, for a reference attribute, a DataManager load of the value — before knowing whether the condition is permitted, matches an existing configuration row, or refers to an existing attribute. The component was then discarded on most paths, and its side effects leaked.

Commits:

1. Parse URL filter conditions into models before creating components — the core change. The URL is parsed into a plain model (ParsedPropertyCondition: property, operation, raw value string); permission checks and the matching against the current configuration run on the model; a component is created — through the same PropertyFilterConverter route the programmatic API uses — only for the conditions that are actually added, and the value is deserialized (which may load a referenced entity) only at that point. A malformed or unresolvable condition degrades to a skipped condition with a warning. The URL format does not change; the replaced protected methods are kept as deprecated delegates to the new flow.
2. Extract the shared URL parameter tokenizer used by the filter binders — the generic filter, property filter and data grid filter binders each hand-rolled the same slicing of a parameter into structural tokens plus the value remainder; it now lives in FilterUrlQueryParametersSupport.splitParameter.
3. Validate the condition operation against the attribute on the model — the operation compatibility used to be checked only inside PropertyFilter.setOperation while the component was being built, where a failure escaped into the navigation; it now runs in the model validation, and an operation outside a component's narrowed operations list is not applied instead of failing the restore.

Resolved by this change:

• GenericFilter: a URL condition on an unknown attribute fails the view navigation instead of being ignored #5630 — a URL condition on an unknown attribute no longer fails the navigation: the attribute is resolved on the model first, the condition is skipped with a warning. The same applies to a malformed condition string and to an operation not available for the attribute (previously also navigation failures, not filed separately).
• The class of GenericFilter: a condition restored from the URL is duplicated in the data loader and freezes its value #5586 (fixed in 3.0.x only, not ported to master) becomes impossible on master by construction: no component is created during parsing, so nothing can write into the data loader condition; added components go through the converter, which sets conditionModificationDelegated.
• Duplicated condition in the composed loader condition (AND[cond, AND[cond]] on every URL restore; observed on 3.0.1 and master, not filed) — gone: the condition appears exactly once, verified on the demo project.
• Wasted DataManager loads for a condition rejected by the permission check (not filed): values are now deserialized only for surviving conditions — a forbidden attribute costs a string comparison, not a query per LIST element.

Tests: GenericFilterUrlConditionModelTest (18 cases incl. a table of adversarial URL inputs; the unknown-attribute, single-occurrence and no-trace cases fail without the fix) and FilterUrlQueryParametersSupportTest (tokenizer). Full :flowui:test and :flowui-data:test pass. The filter-test demo app on this build was swept with Playwright over all 50 scenario views; the only differences from the previous baseline are the fixes above and the known #5516-family gaps of master (its fix lives in the release_3_0 PR queue).

Behavior notes:

• GenericFilter: restoring filter state from the URL fires a redundant data load when a condition operation differs #5655 (the redundant intermediate load during the URL restore) is deliberately not part of this PR: it is fixed in the release_3_0 line by GenericFilter: restoring filter state from the URL fires a redundant data load when a condition operation differs #5659 (stacked on One condition is shown but another is applied in GenericFilter #5634) and will reach master with its forward-port.
• The skip policy for conditions that cannot be applied is unchanged (they are dropped or left empty; the UI stays consistent with the query) — only the logging level is raised to warn.

🤖 Generated with Claude Code