perf: constant propagation and OR→IN conversion for index use

[iheitlager]

Summary

Carried forward from #531 (epic #421, closed without full completion). Two
expression-level optimizations are unimplemented — verified via codebase
search (no matches for constant propagation or OR→IN conversion anywhere
in src/; only the unrelated cheapest-first AND/OR ordering, #581, is done).

Techniques

Technique	Description	Priority
Constant propagation	a=b AND b=5 → deduce a=5 for index use	High
OR → IN conversion	x=1 OR x=2 OR x=3 → x IN (1,2,3)	Medium

Example

-- Without constant propagation:
SELECT * FROM a JOIN b ON a.x = b.y WHERE b.y = 5
-- Doesn't know a.x = 5, misses index on a.x

-- With constant propagation:
-- Deduces a.x = 5, uses index on a.x

Acceptance criteria

• a=b AND b=5 enables index on a
• OR chains of equality on the same column converted to IN
• expr_heavy benchmark improves from 1.76×

Complexity

Estimate: medium
Reasoning: Constant propagation requires tracking equality-implied
constants through WHERE/JOIN-ON expression trees and feeding them into the
planner's index-eligibility checks — touches both expression analysis and
src/planner.rs. OR→IN conversion is a more local expression-rewrite pass
but still needs care to preserve semantics (same column, pure equality
terms only, no mixed operators).

Refs: #531