fix(schema-compiler): multi_stage leaf measure missing FROM clause

[TheRoot-1]

Summary

• Fixes a crash in renderWithQuery when a multi_stage measure's sql has no {} measure dependencies (leaf node in the dependency graph)
• memberFrom is null for leaves, causing fromSubQuery → fromSql to be null, which triggers the error check: "Multi stage member '...' lacks FROM clause in sub query"
• Adds a fallback: when fromSubQuery was never built and the withQuery has measures, build a subquery directly from the cube's own table

Fixes: #10549
Related: #9241

Test plan

• Added unit tests in base-query.test.ts covering:
  • Leaf sum measure does not throw
  • CTE query is generated (multi_stage path is taken)
  • Filters propagate through the leaf fallback subquery
  • avg type works as well as sum
• All existing unit tests pass (466 tests, 464 pass, 2 pre-existing failures in error-reporter.test.ts)

[TheRoot-1]

Context on how this surfaces: this edge case came up when auto-generating Cube schemas from another modeling tool. The converter produced multi_stage: true on leaf measures that reference columns directly (sql: amount) rather than other measures via {}.

The intended Cube pattern is a chain where the leaf is a regular measure and multi_stage is on the derived measure. We're aware of that and are fixing the converter separately. This PR handles the case gracefully rather than throwing an unhelpful error.

[TheRoot-1]

Converting to draft — some findings since opening:

Tesseract has the same bug. The Rust planner flags leaf measures via is_without_member_leaf in plan_for_leaf_cte_query() but produces FromSource::Empty (empty string), resulting in invalid SQL with no FROM clause. This PR only fixes the JS planner path.

This may not be an intended use case. Every multi_stage example in the test suite uses {} measure references. A leaf with sql: amount, multi_stage: true and no {} dependency isn't the expected pattern. A schema-level validation error might be more appropriate than a runtime fallback.

Leaving as draft until the team weighs in on the preferred approach — see #10549 for the full discussion.