feat: support string manipulation functions in queries

[dodok8]

Objective

Add explicit string manipulation functions to the query language without overloading arithmetic operators or exposing SQLite-specific string operators directly.

Motivation or use case

Arithmetic expressions are numeric-only. String operations still need a typed surface for common query use cases such as concatenation, normalization, length checks, trimming, replacement, and substring search. Keeping these operations as named functions avoids SQLite coercion semantics and keeps Gelite's query contract explicit.

Expected outcome

The query language supports a scoped set of string functions with resolver-level type checks and SQLite lowering.

Initial function candidates:

• concat(a, b) -> str: concatenates exactly two string values. SQLite || is not exposed directly.
• length(value) -> int64: returns text length using the documented Gelite semantics.
• lower(value) -> str
• upper(value) -> str
• trim(value) -> str
• ltrim(value) -> str
• rtrim(value) -> str
• replace(value, from, to) -> str
• substr(value, start) -> str
• substr(value, start, length) -> str
• Predicate helpers such as contains(value, needle) -> bool, starts_with(value, prefix) -> bool, and ends_with(value, suffix) -> bool should be considered in the design before implementation.

The final supported set can be smaller than this candidate list if the spec narrows the MVP.

Scope

• spec/query.md: define string function syntax and semantics.
• spec/ir.md: define resolved function or string operation IR.
• engine/query-parser: parse function-call expressions if the syntax is not already supported.
• engine/query-ast: represent function-call expressions.
• engine/query-ir: represent resolved string value expressions and string predicates.
• engine/query-resolver: validate function arity and argument types.
• engine/sqlite-query-plan and engine/sqlite-query-sqlgen: lower supported functions to SQLite.
• Integration tests once execution coverage exists for query functions.

Related specs and plans

• spec/query.md: should define the query-language surface syntax for function calls.
• spec/ir.md: should define the semantic IR shape and type guarantees.
• spec/sqlite-query-plan.md: should define SQLite-specific lowering for supported functions.
• Related to feat: support arithmetic expressions in filters #12 because arithmetic expressions remain numeric-only and string operations need a separate typed path.

Boundaries and non-goals

• Do not make + concatenate strings.
• Do not expose SQLite || directly in Gelite syntax; use concat(a, b) for string concatenation.
• Do not rely on SQLite implicit type coercion for string functions.
• Do not add user-defined functions in this issue.
• Do not add SQLite REGEXP, FTS MATCH, or extension-dependent behavior unless a later spec explicitly enables it.
• Do not support variadic concat in the first version; start with exactly two arguments.

Acceptance criteria

• The spec documents which string functions are supported and which are deferred.
• The resolver rejects non-string arguments for string-only functions before SQLite planning.
• concat(a, b) accepts exactly two string value expressions and lowers to SQLite concatenation.
• Tests cover successful string function resolution and type/arity errors.
• SQLite SQL generation tests cover each implemented function.

Branch

Not started.

Checks

• I searched existing issues for the same request or task.
• I checked the relevant spec/ or plan/ document when one exists.

[dodok8]

Concat should provied suppport for multi arugment like concat(a,b,c, ...)

[dodok8]

And we need str()