Context

Currently, nine variadic operator functions in mql/agg/operator.go bind their variadic parameter to a single generic type parameter. Go infers one concrete type for the whole variadic, so every element must be identical.

Affected functions:

• Add, Multiply — [T, U NumberResolver](value T, values ...U)
• Concat — [T, U StringResolver](value T, values ...U)
• ConcatArrays — [T, U ArrayResolver](array T, arrays ...U)
• And, Or — [T BoolResolver](exprs ...T)
• SetEquals, SetIntersection, SetUnion — [T ArrayResolver](exprs ...T)

The T/U split ones (Add, Multiply, Concat, ConcatArrays) allow at most two distinct types; the single-T ones allow only one. Here's an example that would currently fail:

Add("$price", 1, 2.5) // int and float64 cannot both satisfy U

This is not a problem for operators with a per-argument type parameter (Divide, Log, Mod, Pow, Subtract, etc.), nor for operators already using ...Expr (Avg, Sum, Max, Min, MergeObjects, etc.). The fix is to align these nine with the ...Expr pattern already established.

Definition of done

• The nine listed functions accept ...Expr for their variadic parameter, allowing heterogeneous arguments (field refs, literals, and typed exprs mixed in one call).
• The type constraint previously enforced by the signature (e.g. "resolves to number") is documented in each function's doc comment.