Search sidebar JSON resource filters use map access

[mfroembgen]

Summary

After #2537, JSON-backed metadata value/distribution queries are typed correctly, but the Search dashboard sidebar can still serialize a selected resource attribute filter as a map-style expression instead of a typed ClickHouse JSON subcolumn.

This still breaks JSON-schema OTel log/trace sources when a user selects a resource attribute value from the filter sidebar, for example ResourceAttributes.k8s.namespace.name.

Repro

On a source where ResourceAttributes is a ClickHouse JSON(max_dynamic_types=8, max_dynamic_paths=64) column:

1. Open Search for a logs source.
2. Expand/pin ResourceAttributes.k8s.namespace.name in the filter sidebar.
3. Select a namespace value from the sidebar filter values.
4. Run the search or use the distribution button for that filtered attribute.

Actual

The dashboard can persist/send a filter using map access against the JSON column, for example:

ResourceAttributes['k8s.namespace.name'] IN ('traefik-private')

or an untyped JSON path. ClickHouse then sees a JSON/Dynamic value where a concrete string expression is needed and returns errors like:

First argument for function 'arrayElement' must be array, got 'JSON(max_dynamic_types=8, max_dynamic_paths=64)'

Expected

For source columns whose schema type is JSON(...), dashboard filter serialization should emit typed JSON subcolumns, for example:

ResourceAttributes.`k8s`.`namespace`.`name`.:String IN ('traefik-private')

Map-backed attributes should keep the existing bracket syntax.

Notes

• Related to JSON schema filter distribution groups by Dynamic attribute paths #2482 and fix: type JSON metadata filter attributes #2537, but narrower: this is the frontend/search-filter state path rather than common-utils metadata query generation.
• I did not find another open issue or PR that fixes this remaining Search dashboard filter serialization path.