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

Nobody has claimed this yet.

**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.

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.

Written by the indexing model from the issue text.