Two follow-ups from automated review:

1. `_build_execution_sql` (core.py): the helper backing `to_sql()` /
   `explain()`'s SQL preview used `next(seg for seg in segments if
   seg.is_sql())`, which would pick a LATER `SQL-on-Python(__df__)`
   segment when the first segment was Pandas (cost-aware planner for
   `ORDER BY` without `LIMIT`). That returned a `Python(__df__)` SQL
   whose `FROM` does not match the source the executor actually
   issues first. Constrained to the FIRST segment: if it is SQL,
   return that segment's SQL; otherwise fall back to
   `_generate_select_sql` (the `SELECT * FROM <source>` the executor
   runs to materialize rows for Pandas).

2. `_build_layers` (query_planner.py): `mask(...).groupby(...).agg(...)`
   (or `where(...).groupby(...).agg(...)`) kept the LazyMask/LazyWhere
   in the SAME layer as LazyGroupByAgg. The wrapper-layer CASE-WHEN
   temp-alias machinery (`__tmp_<col>__`) then collided with the
   aggregation's SELECT list - the outer SELECT renamed `__tmp_*__`
   columns that the inner GROUP-BY SELECT never emitted, producing
   `UNKNOWN_IDENTIFIER` (DataFrame source) or wrong values
   (file/table source). Now LazyGroupByAgg starts a new nested layer
   when the current layer already holds a LazyWhere/LazyMask, so the
   mask runs in the inner subquery and GROUP BY runs on the masked
   output:
   `SELECT ... agg() FROM (SELECT CASE WHEN ... AS x) GROUP BY x`.

3. `_render_wrapper_layer_sql` (sql_executor.py): the
   `add_row_order_fallback` `ORDER BY _row_id` clause is intentionally
   skipped when wrapping with `__case_subq__`. The `Python(__df__)`
   virtual `_row_id` is not propagated through the inner CASE-WHEN
   SELECT, so referencing it on the outer rename layer would fail with
   `UNKNOWN_IDENTIFIER`. CASE-WHEN is row-preserving, so source order
   naturally flows up through the wrapper.

Regression tests:
- `tests/test_groupby_sql_pushdown.py::TestDispatchByOpType
  ::test_mask_then_groupby_splits_into_nested_layers` and
  `test_where_then_groupby_splits_into_nested_layers` pin both the
  plan structure (2 layers, mask in inner, groupby in outer) and the
  end-to-end value equality vs pandas.
- `tests/test_explain_method.py::TestBuildExecutionSQLFirstSegment`
  covers both branches: SQL-first chain returns source-bound SQL,
  Pandas-first chain returns the initial `SELECT * FROM <source>`
  (never `Python(__df__)`).

Verified: 10477 passed, 0 failed (full suite, remote tests excluded).

Fixes three bugs uncovered by the user-journey + property-based test
sweep introduced on top of PR #577's unified `_build_layer` dispatcher.

1. head-before-agg LIMIT ordering (`query_planner._build_layers`)
   `head(N).groupby().agg()` was folded into one SQL layer, so LIMIT
   ran after GROUP BY and limited the number of groups instead of the
   number of input rows. The planner now starts a new nested-subquery
   layer when `LazyGroupByAgg` follows LIMIT/OFFSET.

2. Post-agg WHERE folded back into pre-agg WHERE (`sql_executor`)
   `result[result['count'] > 0]` after a `groupby().agg(...)` had its
   condition appended to the pre-aggregation WHERE clause, which
   silently bound to the source column of the same name. The first-
   layer renderer now emits the post-agg conditions as a real HAVING
   clause (combined with any user-supplied `self.ds._having_condition`).

3. DataFrame source assign-before-groupby (`sql_executor._build_sql_for_dataframe`)
   `ds.assign(x=...).groupby(...).agg(...)` against a Python() DataFrame
   source emitted `SELECT *, expr AS x, agg(...) ... GROUP BY ...`,
   which ClickHouse rejects with NOT_AN_AGGREGATE. The single-layer
   DataFrame path now routes any plan containing `groupby_agg` /
   `where_ops` / multi-layer through the unified `_build_layered_sql`
   pipeline, and `_build_layer` forces `include_star=False` whenever
   the layer has a `groupby_agg` (the agg's emitted select_fields
   already cover the group keys + aggregations).

Supporting changes in the unified pipeline:
- `_build_layer`: append `col IS NOT NULL` filters for `groupby_cols`
  when `dropna=True` (pandas default) - matches the legacy inline
  DataFrame path that was previously the only place this lived.
- `_render_wrapper_layer_sql`: accept `where_temp_alias_columns` so
  the wrapper layer renames `__tmp_col__` back to user-visible
  column names; postpone WHERE/ORDER BY/LIMIT/OFFSET to the outer
  rename layer so they bind to the masked values (LazyMask/LazyWhere
  semantic); suppress `ORDER BY _row_id` fallback when GROUP BY is
  present (would be NOT_AN_AGGREGATE).
- `_collect_select_fields_from_sql_ops`: unchanged accumulating
  semantics; instead the planner splits a pure-projection SELECT
  into a new layer when an in-layer WHERE references a column the
  projection would drop (e.g. `assign(x=...)[where x>0][['id']]` as
  produced by ColumnExpr's per-column pruning path).

Test coverage:
- 3 previously-xfailed regression tests in `datastore/tests/journeys/`
  (`test_head_before_agg_respects_limit`,
  `test_agg_output_name_shadows_source_column`,
  `test_top_three_revenue_dataframe_source_assign_before_groupby`)
  flipped to permanent passing guards.
- `test_property_based_chains.py` no longer skips the
  head-before-agg / sort-or-select-before-agg chains; remaining
  empty-result groupby cases (pre-existing pandas-vs-DataStore
  column-set divergence) are short-circuited explicitly.
- New `datastore/tests/` files (journeys/, cartesian product,
  naming-conflict fuzz, SQL snapshot assertions, plan invariants,
  property-based chains) introduce ~150 additional regressions.
- Updated `.cursor/rules/chdb-ds.mdc` with multi-step-mirror and
  property-based-sweep test guidelines.
- `requirements-dev.txt`: add `hypothesis>=6.0.0`.

Verified:
- 10473 passed, 0 failed (full suite, remote tests excluded).
- 1000-example hypothesis property sweep passes.
- All 47 journey tests pass (including the 3 flipped xfails).

Two follow-ups from automated review:

1. `_build_execution_sql` (core.py): the helper backing `to_sql()` /
   `explain()`'s SQL preview used `next(seg for seg in segments if
   seg.is_sql())`, which would pick a LATER `SQL-on-Python(__df__)`
   segment when the first segment was Pandas (cost-aware planner for
   `ORDER BY` without `LIMIT`). That returned a `Python(__df__)` SQL
   whose `FROM` does not match the source the executor actually
   issues first. Constrained to the FIRST segment: if it is SQL,
   return that segment's SQL; otherwise fall back to
   `_generate_select_sql` (the `SELECT * FROM <source>` the executor
   runs to materialize rows for Pandas).

2. `_build_layers` (query_planner.py): `mask(...).groupby(...).agg(...)`
   (or `where(...).groupby(...).agg(...)`) kept the LazyMask/LazyWhere
   in the SAME layer as LazyGroupByAgg. The wrapper-layer CASE-WHEN
   temp-alias machinery (`__tmp_<col>__`) then collided with the
   aggregation's SELECT list - the outer SELECT renamed `__tmp_*__`
   columns that the inner GROUP-BY SELECT never emitted, producing
   `UNKNOWN_IDENTIFIER` (DataFrame source) or wrong values
   (file/table source). Now LazyGroupByAgg starts a new nested layer
   when the current layer already holds a LazyWhere/LazyMask, so the
   mask runs in the inner subquery and GROUP BY runs on the masked
   output:
   `SELECT ... agg() FROM (SELECT CASE WHEN ... AS x) GROUP BY x`.

3. `_render_wrapper_layer_sql` (sql_executor.py): the
   `add_row_order_fallback` `ORDER BY _row_id` clause is intentionally
   skipped when wrapping with `__case_subq__`. The `Python(__df__)`
   virtual `_row_id` is not propagated through the inner CASE-WHEN
   SELECT, so referencing it on the outer rename layer would fail with
   `UNKNOWN_IDENTIFIER`. CASE-WHEN is row-preserving, so source order
   naturally flows up through the wrapper.

Regression tests:
- `tests/test_groupby_sql_pushdown.py::TestDispatchByOpType
  ::test_mask_then_groupby_splits_into_nested_layers` and
  `test_where_then_groupby_splits_into_nested_layers` pin both the
  plan structure (2 layers, mask in inner, groupby in outer) and the
  end-to-end value equality vs pandas.
- `tests/test_explain_method.py::TestBuildExecutionSQLFirstSegment`
  covers both branches: SQL-first chain returns source-bound SQL,
  Pandas-first chain returns the initial `SELECT * FROM <source>`
  (never `Python(__df__)`).

Verified: 10477 passed, 0 failed (full suite, remote tests excluded).