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).

The previous empty-result short-circuit in
``test_random_chain_matches_pandas`` checked
``isinstance(ds_result, pd.DataFrame)``, but ``apply_chain`` returns
a lazy ``DataStore``, not a materialized ``pd.DataFrame`` - so the
isinstance branch was always False and the short-circuit never
fired. CI on commit 64f38b8 surfaced this when Hypothesis generated
the chain ``filter(v>0) -> filter(v>99) -> sort(w desc) ->
groupby(cat).agg({'v':'sum'})`` (empty intermediate after the
second filter; column drift between pandas' agg-projected output
and DataStore's source-bound short-circuit output).

Two changes:

- ``tests/test_property_based_chains.py``: replace the isinstance
  check with a duck-typed ``len(r) == 0`` helper that works on
  ``DataStore`` and ``pd.DataFrame`` alike. Reference the new
  journey test in the comment so future readers can find the
  tracked bug.

- ``tests/journeys/test_property_chain_followups.py`` (new): verbatim
  regression for the falsifying chain, marked
  ``@unittest.expectedFailure``. Follows the
  ``.cursor/rules/chdb-ds.mdc`` rule #6 contract: every Hypothesis
  falsifier becomes a permanent journey test; when the underlying
  empty-intermediate column-projection bug in the executor is
  fixed, flip the xfail and drop the property-test skip in the
  same commit.

…survives

The debug log truncated executed SQL at 200 chars with "...". PR
#578 added the ``col IS NOT NULL`` dropna filter to GROUP BY queries
on SQL sources too (previously only DataFrame source). For remote
sources this pushed the SQL from ~200 to ~220 chars, truncating
``GROUP BY`` to ``GROUP B...`` in the log output.

``tests/test_remote_lazy_chain_pushdown.py::test_assign_filter_groupby_agg``
parses the debug log and asserts ``'GROUP BY' in sql.upper()``, so
the truncation made the assertion fail across all 4 CI platforms.

The actual emitted SQL is correct; only the log line was truncated.
Bump the limit to 2000 chars (10x) so typical multi-clause queries
fit in full and the log-parsing tests work again. The full SQL is
still bounded so very large queries don't spam logs.