Filter expression is ignored when resolving the display label in value relation

Start in app/valuerelationcontroller.cpp around line 167 and trace how the collapsed Value Relation field resolves labels versus how the dropdown applies FilterExpression. Done means the collapsed field shows the label from the filtered list, matching the selected dropdown item and QGIS Desktop, including lookup keys shared across lists.

Description
For a Value Relation field, the app resolves the display label with a keyed lookup that does not apply the widget's FilterExpression. When the key column is unique only within the filtered subset (one shared code table holding many code lists, filtered per list) the collapsed
field shows the label of the first row with that key from any list, i.e. the wrong one.

Opening the dropdown shows the correctly filtered list with the correct item ticked; only the collapsed field is wrong. Stored data is not affected.

This is a regression against both older app versions and QGIS Desktop, which resolves the same project correctly.

Internal support ticket: https://odoo.lutraconsulting.co.uk/odoo/my-tickets/16625

Environment
Production

Application (+ app version, build, operating system)
2026.4.0
not reproducible on 2026.2.0
probably introduced in #4525

Steps to reproduce

1. Create a non-spatial lookup table codes holding two code lists in one table. Codes are unique only within a list, and the list we are not interested in sits on the lower fids:

   fid	list_name	code	label
   1	status	0	Unknown status
   2	status	1	Active
   3	material	0	Concrete
   4	material	1	Steel

2. Create a point layer survey_points with an integer field material, and set its widget to Value Relation:

   • Layer codes, Key column code, Value column label
   • Filter expression: "list_name" = 'material'
   • Allow NULL: on (keeps the unrelated "empty saves as 0" behaviour out of the repro)

3. Add one point with material = 0. Within the filtered list this code means Concrete.

4. Open the form in QGIS Desktop - the field shows Concrete. This is the control.

5. Push the project to Mergin, open it in the mobile app, tap the point, open the form.

6. Tap the material field to open the dropdown.

Actual results
Step 5 - the collapsed field shows Unknown status, the label of fid 1, which belongs to the status list and is excluded by the filter.

Step 6 - the dropdown correctly lists only Concrete and Steel, with Concrete ticked.

Expected results

The collapsed field shows Concrete, matching QGIS Desktop and matching what the dropdown shows as selected. This is the case on 2026.2.0

Screenshots
Latest app version

https://github.com/user-attachments/assets/c7b0a177-80f4-49cc-a977-8539546945e2

2026.2.0

https://github.com/user-attachments/assets/02414811-c76c-4be4-8cb8-b7a4716ca970

Extra info - related

1. Multi-select is worse. request.setLimit( keys.size() ) (app/valuerelationcontroller.cpp:167) with keys {0,1} can be satisfied by two rows from the wrong list before the right ones are reached.
2. Static filter + hot reload can null a value. A stored key that legitimately sits outside a static filter already triggers invalidateSelection on the hot-reload path today.
3. Docs. https://merginmaps.com/docs/layer/value-select/#value-relation recommends a UUID key for sync safety (fids change during sync), and describes the filter as limiting "the options in the drop-down menu". It documents no desktop/mobile divergence. If we intentionally keep a global-uniqueness requirement for the key, it needs to be stated there explicitly — the page currently implies the QGIS setup carries over unchanged.