feat(data-table): add filter policy support

[IzumiSy]

Motivation

Some backends only expose a subset of the DataTable filter surface. In particular, operator support can vary per field type, and regex-backed case-insensitive string filtering may be unavailable. Without a way to express those limits, inferred filter UIs could offer controls that the backend cannot execute, and URL-backed filter state could restore unsupported operators.

Design Decision

Chosen approach

Expose backend-wide filter defaults through filterPolicy, applied where metadata-derived FilterConfig objects are created.

This keeps the main override point close to inferColumns() and fieldTypeToFilterConfig(), which already translate metadata into filter behavior. The resolved FilterConfig then drives both the visible filter UI and URL-state hydration.

URL state behavior

useURLCollectionVariables() and withURLCollectionState() now accept the same filterPolicy so URL hydration validates operators against the effective filter config.

For string filters, URL hydration restores the field's default case-sensitivity from supportsCaseInsensitive instead of adding a new URL format for that flag.

Alternatives considered

A control-level capability API was considered, but that would push backend policy into runtime control wiring for a case that is usually static per app/backend. A metadata/inference-level policy keeps the common path smaller and avoids extra wrapper code for each table.

Summary

• add operators and supportsCaseInsensitive to FilterConfig, plus public FilterPolicy support in metadata-derived filter config helpers
• allow inferColumns() to apply backend-wide filter policy defaults to inferred filter configs
• make DataTable filter UI and URL-backed collection state respect the effective filter policy