Plan the binary condition nodes' collation and data-driven definitions

[trueqbit]

Stacked on #1564: based on its branch, so this diff shows only the changes on top of it.

Summary

A plan, no code: docs/plans/2026-10-04-binary-condition-nodes-plan.md, linked from the "Internals" section of TODO.md. It lays out three steps for the binary conditions in dev/ast/binary_condition.h:

1. A collatable<Self> base. It holds the five collation members (collate_binary(), collate_nocase(), collate_rtrim(), collate(name), collate<C>()) once. Today the six comparisons repeat them, 30 functions in all. No change for consumers.
2. Collation for IS / IS NOT / IS [NOT] DISTINCT FROM. SQLite applies collating sequences to these as well, but sqlite_orm doesn't offer it yet. This is a feature, so it's planned as a separate commit or PR that can be left out.
3. The conditions as aliases over one node, like the binary operators since Move the operators to ast/ and classify them by trait #1552 (using add_t = binary_operator<L, R, add_string, ...>). Collatability and the result type would be carried by tags. This step would follow Move the operators to ast/ and classify them by trait #1552's merge.

The plan also covers:

• the current state of the condition nodes;
• the C++17 constraints of step 3, where members can't be selected by tag without requires, so it needs a conditional CRTP base;
• the consumer impact, which in step 3 is limited to longer type names in compiler diagnostics;
• the sequencing;
• two open questions: one node for conditions and operators, and collation for BETWEEN, IN and ORDER BY.

It's stacked on #1564 because #1564 changed the condition factories' return types to unwrap c()-quoted operands, and step 3 builds on that.

🤖 Generated with Claude Code