REGRESSION (26.0.4+): FK navigation applies the filter but no longer shows it in the filter panel, so it cannot be removed #41933

Description

After navigating a foreign key from a data cell (Navigate link, or right-click cell -> Navigate -> Navigate link), the target table opens correctly filtered to the referenced row, but the filter expression is no longer shown in the filter panel. The panel stays empty ("Enter a SQL expression to filter results").

Because the condition is not present in the filter panel any more, it cannot be edited or removed. This breaks a very common workflow:

1. Click a FK cell to jump to the referenced row.
2. Clear the id = <value> condition in the filter bar.
3. Browse the whole referenced table, in context, without leaving the editor.

Expected (and the behaviour up to 26.0.3): the filter bar shows id = 33 and clearing it re-reads the full target table.
Actual (26.0.4 and later): one row is displayed, the filter bar is empty, and there is no condition to remove.

A colleague on 25.3.0.202511301802 still has the correct behaviour on the same database, same driver.

DBeaver Version

Community Edition 26.1.3 (also reproduced by inspection on 26.0.4, 26.0.5, 26.1.0, 26.1.5)

Operating System

macOS 15 (Darwin 25.6.0), Apple Silicon

Database and driver

Database: PostgreSQL 15
Driver: PostgreSQL JDBC (bundled)

Steps to reproduce

1. Open any table that has a foreign key column, e.g. public."user" with role_id -> public.role(id).
2. Put the cursor on a FK cell and use Navigate link (Alt+Space, or right-click -> Navigate -> Navigate link).
3. The editor navigates to role and shows exactly the referenced row.
4. Look at the filter panel above the grid.

Additional context

Version bisect. I decompiled org.jkiss.dbeaver.ui.editors.data for each release and looked at ResultSetViewer.setDataContainer(DBSDataContainer, DBDDataFilter). A call to ResultSetModel.setDataFilter(dataFilter) was added there, immediately before runDataPump(...). The change lines up exactly with the versions where the behaviour breaks:

Possible cause: at that point model still holds the attributes of the source table, so ResultSetModel.setDataFilter merges constraints built for the source columns into the navigation filter that was built for the target entity. After the pump completes and the model is rebound to the target attributes, updateFiltersText() produces an empty string from SQLUtils.appendConditionString(model.getDataFilter(), ...), even though the generated query did apply the WHERE clause.

The navigation filter itself still looks correct where it is created - DBDReferenceUtils.resolveAssociationNavigation builds a DBDAttributeConstraint with setVisible(true), operator EQUALS and the referenced value - so the condition appears to be lost on the way into the model rather than never created.

I have not built from source to confirm the exact mechanism; the version correlation above and the two machines side by side are what I can verify.

Related, same UI strip, both reported as regressions before: #38660 and #40051.