feat(ui): resolve select filterOptions in the list view where builder

[paulpopus]

What

The list view where (filter) builder ignored a select field's filterOptions function. The filter value dropdown always showed the full static options list, even when filterOptions was defined to narrow or fetch that list dynamically (e.g. from the database).

Why

filterOptions was already resolved server-side for relationship fields, producing a Where query keyed by collection. select fields use filterOptions differently: it returns a filtered Option[] instead of a Where query. Because resolveAllFilterOptions only handled the relationship shape, select filtering was not used.

How

• Extend resolveAllFilterOptions to also call a select field's filterOptions function, awaiting async implementations, and store the resulting Option[] in the same resolved map used for relationship fields.
• Widen resolvedFilterOptions and filterOptions prop types from ResolvedFilterOptions to Option[] | ResolvedFilterOptions across the list view and where builder component chain, so both shapes can flow through unchanged.
• In WhereBuilder/Condition, use the resolved Option[] for the filter value options when present, falling back to the field's static options otherwise.
• In DefaultFilter, only pass the resolved value through to RelationshipFilter when it is a Where query, avoiding an Option[] being mistaken for relationship filter options.

[github-actions]

📦 esbuild Bundle Analysis for payload

This analysis was generated by esbuild-bundle-analyzer. 🤖
This PR introduced no changes to the esbuild bundle! 🙌