feat(explore): support numeric comparison ops on TYPE_ARRAY keys

[manessaraj]

Enable field[*]:>N / <N / >=N / <=N against TYPE_ARRAY columns in the RPC layer. Previously rejected: only =/!=/LIKE were allowed.

Example generated query (from TestArrayWildcardSearch::test_trace_item_table_array_op_greater_than_int,
filter frame_linenos[*]:>50):

    SELECT
        cast(lower(leftPad(hex(item_id), ..., '0')), 'String')
            AS `sentry.item_id_TYPE_STRING`,
        toJSONString(attributes_array.`frame_linenos`::Array(JSON))
            AS frame_linenos_TYPE_ARRAY
    FROM eap_items_1_local
    WHERE in(project_id, [1, 2, 3])
      AND equals(organization_id, 1)
      AND less(timestamp, toDateTime('2026-05-11 15:00:00'))
      AND greaterOrEquals(timestamp, toDateTime('2026-05-11 09:00:00'))
      AND arrayExists(x -> greater(x.`Int`::Nullable(Int64), 50),
                      attributes_array.`frame_linenos`::Array(JSON))
      AND equals(item_type, 1)
    LIMIT 10001 OFFSET 0

[linear-code]

EXP-945

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit e729799. Configure here.}

[cursor]

Missing space in error message string concatenation

Low Severity

The error message uses implicit Python string concatenation between the f-string on line 375 and the plain string on line 376, but there's no space between "value" and "(val_int...". The resulting message reads "...requires a numeric value(val_int, val_float, val_double)" instead of "...requires a numeric value (val_int, val_float, val_double)". The test regex match="on array keys requires a numeric value" still passes because it doesn't cover the parenthesized suffix, so this won't be caught by tests.

 

^{Reviewed by Cursor Bugbot for commit e729799. Configure here.}

[onewland]

The idea behind this change is suspect to me (that it's valuable to our users to be able to do comparison operations to filter rows by index-unspecified array elements) but this approach is acceptable if we are stipulating that this functionality itself is useful.

I would not expect it to perform well (in terms of rows processed/s) as a filter, but that might be fine if your other filters narrow the search enough.