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; apply() and the Apply button 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 GenericFilter.apply() and the Apply button (and its shortcut) recompose before loading, and a standalone GroupFilter.apply() does the same regardless of autoApply; a group inside a GenericFilter still leaves the composition to its owner.

Tests: GenericFilterApplyAfterBaseChangeTest (flowui) — apply() and the Apply button after the base was replaced, autoApply=false for both components, repeated apply() does not accumulate conditions, exactly one load per apply, the empty configuration without a base, a standalone GroupFilter on apply() and on a child operation change, and the delegated root group leaving the loader condition to its owner. Six of the eight fail without the fix. Full :flowui:test and :flowui-data:test 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.

Known limitation, to be addressed in a separate issue after this PR is merged: changing a condition value (Enter / dropdown) or the operation of a condition inside a GenericFilter does not reach the owner's composition — the condition component loads the data loader directly. The gap exists only between the application's setCondition(...) and the next composition (apply(), Apply button, configuration switch): once composed, value and operation changes work again, so the pattern setCondition(...); apply() is fully covered. Applications that replace the loader condition and leave the load to the user still see the base alone until Refresh. Closing it needs a delegation of apply() from a condition to its owner (an addition to FilterComponent), which is why it is not part of this maintenance fix.

Two behaviours worth knowing when reviewing:

• After apply() / Refresh on the empty configuration without a base the loader condition is an empty AND instead of null (the same state Reset and a configuration switch already produced). Queries are unaffected — LogicalCondition.actualize() collapses it — only application code checking getCondition() == null afterwards would notice.
• The base is adopted when the loader condition object is replaced; conditions added in place to the loader's current LogicalCondition are not detected (pre-existing, unchanged; documented as a known characteristic).

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: both conditions, 4 Open orders.
• Scenario 26 (standalone GroupFilter), Replace base, then apply() and Replace base only + change the Status 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

[KremnevDmitry]

1. Value/operation edits still load by the replaced base (autoApply=true, the default).
Neither gesture reaches the patched entry points: a value change goes through SingleFilterComponentBase.apply() (loads directly, no recompose), an operation change goes through the delegated root group's apply() (skips recompose, still loads). So after dataLoader.setCondition(newBase), both gestures load by newBase alone while the UI shows the configuration — the most common reproduction path of #5516. Acknowledged in the description, but worth a tracked follow-up issue. Also, the comment “A delegated group leaves this to its owner” overstates: the owner is never invoked on this path — better phrased as a known limitation.

2. Same gap for a nested group inside a standalone groupFilter — not covered by the disclosed “inside a GenericFilter” limitation.
The operation-change listener calls the nested (delegated) group's apply(), which skips recompose and loads the bare base; the owning group is never notified. A direct child of the standalone group recomposes correctly (tested), so behavior differs one nesting level deeper. Reachable via plain XML.