[codex] add logical OR support

[thiremani]

Summary

• Add || as a logical OR operator distinct from bitwise |.
• Support || in statement conditions with scalar I1 OR lowering.
• Support value-position || as left-biased conditional fallback, including plain fallback values such as a < 5 || 10.

Validation

• python3 test.py tests

[thiremani]

Review: logical OR support

Overview

This PR adds || as a logical OR operator distinct from bitwise |, in three roles:

1. Statement conditions — short-circuit scalar i1 OR (x = a > 2 || b < 5 99)
2. Value-position fallback — left-biased conditional value selection (x = b > 2 || d < 10)
3. Plain fallback / default values — (x = b > 2 || -1), giving Pluto a default-value idiom

Are the changes useful/needed? Yes.

• Before this PR Pluto had no OR at all for conditions — comma gives AND, but expressing "either condition" required restructuring into multiple statements. This is a genuine expressiveness gap being filled.
• The value-position fallback semantics are a natural extension of Pluto's existing conditional-value model (CondScalar LHS extraction), and the "default value" form (|| -1) is a particularly useful idiom — see the LogicalOrArrayDefault test.
• Short-circuiting is real, not just documented: LogicalOrStmtShortCircuit proves the RHS (an out-of-bounds index) is never evaluated when LHS is true. That makes || usable as a guard, which bitwise | could never be.
• The deliberate omission of && is well-reasoned in the code comment (comma conditions already provide statement-position AND; chained comparisons refine values). Worth documenting in user-facing docs, since C-family users will look for it.

Verified during review

• Lexer: no lexer change needed — readOperator consumes maximal operator runs, so || lexes as one token. Confirmed 6 | 3 regression test guards bitwise OR.
• Precedence: COND_OR sits between COMMA and BITWISE_OR, matching conventional C precedence (|| lowest of the operators). Correct placement.
• Arity safety: typeLogicalOrExpression indexes right[i] by len(left), but the pre-existing length-mismatch check in TypeInfixExpression runs first, so no panic path. Multi-value fallback (Pair(...) > Pair(...) || Pair(7, 8)) is covered by tests.
• CI: both test jobs green.

Minor findings (none blocking)

1. compileLogicalOrCondition (compiler/compiler.go): asymmetric freeTemporary. freeTemporary(expr.Left, left) is called only on the true path; on the RHS path the left operand's temporaries are never freed. This is harmless today because condition operands are type-constrained to i1 (never heap) — but by the same logic the true-path free is dead code. Suggest either removing it or freeing on both paths with a comment, so a future reader doesn't infer the wrong invariant.

2. Code-size growth from continuation duplication. compileFallbackOr/compileYield compile the onTrue continuation once per success arm rather than merging arms with a phi before invoking it once. A chain a>1 || b>2 || c duplicates the consumer linearly (fine), but ORs in separate operands multiply: (b>2 || d<10) + (a>10 || c>2) compiles the add 4 times, and m OR-bearing operands give 2^m copies of the consumer. Realistic code won't hit this, but a phi-merge per OR (like compileLogicalOrCondition already does for conditions) would bound it if value-position ORs proliferate. Fine as a follow-up.

3. Test coverage gap: no negative/type-error tests. All 26 new .spt cases are success paths. The new diagnostics are untested: non-i1 condition operands (1 || 2 in condition position), mismatched value types (a > 1 || "str"), and "logical OR in value position requires a conditional left operand" (5 || 10). Worth adding if there's an error-fixture mechanism.

4. Nit: ast.IsLogicalOr (free function) and (*InfixExpression).IsLogicalOr (method) are near-duplicates; harmless, but the free function alone would suffice.

Code quality

The refactors are tasteful: compileCondExprBranch → branchCond gaining an onFalse hook is the minimal generalization needed, extractCondComparison is a clean extraction, and CondOr slots into the existing CondMode machinery rather than inventing a parallel path. The panic("internal: value-position logical OR must be lowered...") guard in compileInfixBasic is good defensive practice. Parser boundary handling (first || binds to the statement condition, second to the value) is subtle and well-tested.

Verdict: the feature is well-motivated and the implementation is solid. Recommend merging after considering the minor notes above (especially #3).