Field‑conditions using dynamic values do not trigger any UI behavior

### Describe the Bug

Field‑conditions that reference other fields via dynamic values such as `{{ b }}` do **not trigger** any UI behavior (visibility, required state, disabled state, etc.), even when the underlying condition is logically true. The issue is not limited to the “required” flag; it affects all condition types (show/hide, disable, and any field‑state logic).

The same condition works correctly when the dynamic value is replaced with a static literal (e.g., a fixed string or number), which confirms that the condition engine itself is working but that dynamic‑field references are not being resolved inside field‑condition filters.

### To Reproduce

1. Create a collection with three fields:
- Field `a` (any scalar/text type).
- Field `b` (same type as `a`).
- Field `C` (any type).
2. Open **Settings → Data Model → [your collection]** and edit field `C`.
3. Set up a condition such as:
- Field: `a`
- Operator: `equal`
- Value: `{{ b }}`
4. Then choose **any** behavior for `C` when this condition is true, for example:
- Show / hide `C`
- Disable `C`
- Mark `C` as required
- Any other UI‑state tied to the condition.
5. Create a new item and set both `a` and `b` to the same value.
6. Observe that **none** of the configured behaviors for field `C` are applied.

### Verification:
- Edit the same condition and replace `{{ b }}` with a static literal (e.g., `"same_value"`).
- Create a new item where `a` equals that literal.
- All configured behaviors (show/hide, required, disable, etc.) now work correctly, proving that the problem is specifically the dynamic‑value resolution in field‑conditions.

### Directus Version

v11.17.4

### Hosting Strategy

Self-Hosted (Docker Image)

### Database

PostgreSQL