Classify a quoted condition as a conditional operand

[trueqbit]

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

Summary

|| is the logical OR for conditions and the string concatenation otherwise. The two operator|| overloads told them apart by the raw operand types, and quoted_expression_t is not a condition, so a c()-quoted condition always took the concatenation:

c(eq(&User::id, 1)) || c(eq(&User::id, 2))  // was: conc_t, serialized as `||`
eq(&User::id, 1) || eq(&User::id, 2)        // or_condition_t, serialized as OR

That contradicts what #1564 establishes: a node built from c(x) is the very node built from x. A quoted condition is now classified as a conditional operand: c(cond1) || c(cond2), c(cond1) || cond2 and cond1 || c(cond2) now all build the OR that cond1 || cond2 builds.

Only || needed this: it is the one overloaded operator with two meanings. && accepts any operator argument and already built an and_condition_t from quoted conditions.

The classification lives on the operand axis, not in the || overloads, as the vocabulary layer intends for an operand-only node such as the quoting wrapper:

• is_conditional_operand_v becomes an open trait with a SFINAE slot, like is_operator_argument_v (vocabulary/traits/operand_traits_fwd.h);
• its condition_t base rule is now a specialization in tags.h, so every node inheriting condition_t is classified as before;
• ast/quoted_expression.h classifies a quoted operand as the operand it quotes, next to its is_operator_argument_v specialization.

The || overloads are unchanged; they ask the trait about their operands as before. The other operand traits (arithmetic, negatable, chainable) are left as they are: a quoted operand already passes wherever they are checked, via is_operator_argument.

Consumer-visible change

Code that relied on c(cond1) || c(cond2) concatenating two conditions now gets their OR. Concatenating conditions on purpose remains available explicitly as conc(cond1, cond2). Concatenation of non-conditions, e.g. c(&User::name) || "a", is unchanged.

This is also half of the trap reported in #1575 (c(match<Post>("cat")) || c(match<Post>("dog")) serializing ||); the other half, match() results not being conditions at all, follows in a separate PR stacked on this one.

Test plan

• tests/static_tests/quoted_operands.cpp, new section "logical or concatenation":
  • c(cond1) || c(cond2), c(cond1) || cond2 and cond1 || c(cond2) have the type of cond1 || cond2, an or_condition_t;
  • c(cond1) && c(cond2) has the type of cond1 && cond2;
  • is_conditional_operand holds for c(cond1), and not for c(&User::name);
  • c(&User::name) || "a" and c(&User::name) || c("a") still build a conc_t.

🤖 Generated with Claude Code