feat: support SOQL SET OPTIONS literals and query options binds

[nawforce]

Closes #165.

Standalone query() now accepts terminal SET OPTIONS (dataspace = '…', honorEmptyStrings = true|false) lists and whole query-options binds using the existing boundExpression : COLON expression rule. Inline Apex accepts query-options boundExpression syntax, verified against pre-release at API 68.0 with empty options, identifier/method-call binds, and count/aggregate queries. Inline literal lists remain rejected. Existing query/select/from/grouping contexts and bound-expression visitor reachability are preserved.

Bind expressions are parsed consistently across entry points without an identifier-only predicate. Parenthesized/member/method-call expressions and syntactically valid but inappropriate values such as :true, :'package', and :opts + 1 retain their expression AST for consumer diagnostics. Parsing acceptance is not a guarantee of Database.QueryOptions type or platform legality in dynamic SOQL. Execution-aware consumers must check bind types, supported placeholder/expression forms, and managed context; queryWithBinds() keys must be validated against the supplied map rather than resolved as static Apex variables. Current apex-ls lacks options-specific validation and does not parse arbitrary dynamic strings.

Primary evidence:

• SOQL SET OPTIONS reference: parenthesized assignments, literal types, DLO/simple DMO requirements, managed-dynamic namespace restriction. Exact examples were read from the primary HTML code-block attributes.
• Summer ’26 developer guide: clause at the very end of the query.
• Winter ’27 managed query release note: Boolean builder option, whole bind, query() / queryWithBinds() examples.

Context matrix and exact sanitized live probes record actual outcomes, including a map-only key with no same-named Apex variable. REST literal queries succeeded; dynamic Apex literals failed at runtime and inline literals failed compilation (with indirect compiler diagnostics). This separates live inline bind support from the documented managed-dynamic namespace behavior. An undocumented REST namespace Boolean was accepted by the org but is intentionally excluded from this grammar.

Validation: npm run init; npm run build (196 TypeScript tests, 195 JVM tests); SAMPLES=/Users/kevinjones/adt/apex-samples npm run systest against v1.4.0 (100 tests and 100 snapshots passed on the final build); commit hooks (ESLint/Prettier); git diff --check. GitHub CI for commit a9d5908 passed the full build and sample-system-test workflow. Regressions cover acceptance, malformed/misplaced clauses, unsupported literal values, identifier compatibility, permissive bind-expression parsing and traversal, and list/count/aggregate AST shape.

Limitations: no discoverable Data 360 objects and no managed package/subscriber setup, so DLO/DMO behavior and namespace semantics were not verified live. Object eligibility, bind value types and managed execution constraints remain semantic; standalone parsing cannot distinguish REST from dynamic Apex. No invented namespace-string forms, static namespace resolution, API gate, or subquery expansion.

Follow-up for apex-ls: adopt the parser dependency and add verified inline bind/standalone query regressions for bind traversal and list/count/aggregate result typing. Options-specific type/context checks must retain the options-clause bind separately from the flattened bind list; dynamic API validation must distinguish map keys from Apex variables. Database.QueryOptions declarations remain apex-ls#595. No changes outside apex-parser and no analyzer reproduction claimed.