LynxDB backend: lower positional array index `field[N]` to SPL2

[mostafa]

Context

Array matching (#158, PR #159) added positional array indexing field[N]. The evaluator resolves it to element N, and the PostgreSQL backend lowers it to JSONB ->n / ->>n in JSONB mode. To avoid silently-wrong queries, backends that cannot express it now reject an indexed field with UnsupportedArrayMatching via the new Backend::supports_field_index capability (crates/rsigma-convert/src/backend.rs). LynxDB returns the default false, so args[0]: '...' currently errors.

Why this is feasible

SPL2 (the LynxDB target dialect) does support positional access:

• mvindex(field, n) (0-based, negative indices count from the end, NULL on out-of-range).
• Bracket access expressions: arr[n], chained cities[i].Bridges[j], in eval/where/SELECT.
• JSON helpers: json_extract(json, "path"), json_array_to_mv, mv_to_json_array.

Implicit any-member matching is already native to SPL multivalue fields (field=value matches any member).

Scope

• Implement LynxDbBackend::supports_field_index and lower field[N] to the appropriate SPL2 form valid inside the FROM <index> | search ... filter context (validate mvindex vs bracket access against a real LynxDB instance, since the search-command grammar differs from eval/where).
• Decide whether implicit any-member needs any special handling or is already correct via native multivalue semantics.
• Object-scope [any]/[all] correlation blocks remain out of scope: they need spath + mvexpand, which change event cardinality and do not fit a pure search filter. They should keep returning UnsupportedArrayMatching.
• Add golden tests once the valid SPL2 form is confirmed.

Out of scope

• Negative indices [-1] (tracked separately with the engine/spec follow-up).
• Object-scope correlation blocks on LynxDB.

See the Array Matching guide for the construct semantics and the per-backend support matrix.

Notes

@OrlovEvgeny This might be of your interest.