One condition is shown but another is applied in GenericFilter

[fractal3000]

See #5516

GenericFilter composes the data loader condition as base AND current configuration, where the base is whatever the application set on the loader itself. Until now that composition ran only when the configuration was switched; every other applying gesture just loaded. When the application replaced the loader condition after a configuration was already active (allowed since #5400), the loader kept loading by the new base alone while the filter showed the configuration's condition.

Now every applying gesture recomposes before loading — but only when the loader condition actually diverged: the filter remembers the condition object it set last (lastConditionSetByFilter, the rule introduced by #5400) and recomposes only if the application has replaced it since. An untouched loader condition is not rewritten, so applications that never replace the base see byte-for-byte the previous behavior. The covered gestures:

• GenericFilter.apply(), the Apply button and its shortcut; a standalone GroupFilter.apply() — recompose in place;
• a condition value change (Enter, a dropdown selection) and an operation change, which load the data loader directly from the condition component or from the delegated group: before such a load the component invokes a recomposition delegate — a callback to the owning GenericFilter or standalone GroupFilter, maintained by the owner itself (a group hands its chain to children in add() and clears it in remove(), the filter sets it on a configuration's root group, the converters set it on components they create). Works at any nesting level, including a group nested in a standalone groupFilter; DataGridHeaderFilter stays outside this wiring, which is pinned by a test.

Tests: GenericFilterApplyAfterBaseChangeTest (flowui, 12 cases) and DataGridHeaderFilterApplyTest (the header filter is outside the recomposition wiring) — apply()/Apply button/value change/operation change after the base was replaced, for GenericFilter and standalone GroupFilter incl. a nested group, autoApply=false variants, repeated apply() does not accumulate conditions, exactly one load per gesture, the empty configuration without a base, and the delegated root group leaving an untouched loader condition alone. Six of the original eight fail without the apply-path fix; the four gesture cases fail without the gesture fix. Full :flowui:test (1122) and :flowui-data:test (31) pass; the filter-test scenario app was swept with Playwright on 3.0.1 and on this branch — 47 views, the only differences are the scenarios that reproduce this issue.

Notes for review and release notes:

• Behavior change (the point of the fix). After dataLoader.setCondition(...) while a configuration is shown, any applying gesture composes base AND configuration. An application that replaced the loader condition specifically to override the filter will see the configuration re-applied. Repro: replace the loader condition after a configuration is active, then press Enter in a condition field.
• Known characteristic. Two filters on one DataLoader: alternating applying gestures adopt the neighbour's composition as the base and re-add their own output — the condition tree grows with duplicate (idempotent) AND entries; query results stay correct. Repro: GenericFilter + standalone groupFilter on one loader, alternate gestures between them. Root cause is the shared loader condition, out of scope here.
• Remaining gap (unchanged by this PR). A standalone propertyFilter/jpqlFilter that is not part of a composite filter, and a configuration whose condition components are all invisible, still load by a replaced base. Both are reachable only programmatically.
• Pre-existing, filed as GenericFilter: restoring filter state from the URL fires a redundant data load when a condition operation differs #5655. During URL restore, an operation change fires an intermediate load (GroupFilter.add registers an unconditional operation-change listener). This PR does not change the number of loads; the fix is GenericFilter: restoring filter state from the URL fires a redundant data load when a condition operation differs #5659, stacked on this PR.

QA (filter-test from #5586, Scenarios 16, 25, 26 — the attached archive of #5586 predates 25/26; the current project has them):

• Scenario 16, Set base AFTER activation (amount ≥ 100): the label must show AND[amount greater_or_equal 100, AND[status equal OPEN]] and only Open orders — not amount greater_or_equal 100 alone.
• Scenario 25, Replace base only, then the filter's Refresh, or a change of the Status value, or of its operation: both conditions, not the base alone.
• Scenario 26 (standalone GroupFilter), Replace base, then apply(), and Replace base only + change the Status value or operation: both conditions.
• A view with a filter and no configuration selected: Refresh still loads all rows; no errors.
• autoApply="false": pressing Apply after the application replaced the loader condition loads by both conditions.

🤖 Generated with Claude Code

[fractal3000]

Rework pushed: 12890bbb48 (a delegate instead of the interface + traversal, dedup, a header-filter test) and 4155278db6 (a quality pass over the final diff). :flowui:test is green, both gestures (value / operation change after the loader condition was replaced) verified on the demo project, and the UI sweep shows no behavior change.