Investigated issue #445 and identified optimization opportunities for live query init:

Key findings:
- PR #732 already fixed primary issue (WHERE clause combining)
- Identified 7 additional optimization opportunities
- Lazy compilation (#1) offers highest impact with lowest risk
- Progressive initial loading (#2) improves large dataset performance

Analysis includes:
- Detailed initialization flow diagram
- 7 optimization opportunities with code examples
- Impact/effort/risk assessment for each
- Implementation priority recommendations
- Measurement instrumentation suggestions

Top recommendations:
1. Lazy compilation - delay pipeline compilation until first sync
2. Progressive loading - batch initial snapshot loads
3. Query validation caching - avoid redundant tree traversals
4. Optimizer iteration reduction - faster convergence detection

The document serves as a roadmap for further performance improvements.

1. Join condition parsing (join.ts):
   - Add isBinaryExpression() type guard
   - Throw clear error for complex conditions (and/or) that can't be
     decomposed into left/right for the current IR
   - Document the limitation in JSDoc

2. Explicit clause processing order (core.ts):
   - Add CLAUSE_ORDER array instead of relying on Object.entries() order
   - Order: join → where → groupBy → having → select → orderBy → distinct → limit → offset
   - Warn on unknown clause keys (catches typos)

These changes address issues #2 and #5 from reviewer feedback.

…iew #2)

Expected-fail scenarios throw at the assertion, before their `h.unmount()`, so
the mounted framework root leaked (observed with Solid on error-status and the
universal order-only-move). Wrap the driver's mount* methods to track handles
and tear them all down in a finally around each scenario, so teardown runs
regardless of whether the scenario throws.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>