The exact count optimization can now compute `count()` results from
primary key analysis without reading data, so `count()` queries bypass
the `max_rows_to_read` limit on MergeTree tables. Update the test to
expect success for `count()` queries and add `SELECT *` tests to verify
that non-count queries still respect the limit.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

The exact count optimization that bypasses `max_rows_to_read` only works
when `optimize_use_projections` is enabled. Since CI randomizes this
setting, the test must keep the original `TOO_MANY_ROWS` expectations
for `count()` queries on MergeTree tables.

The C++ fix in the previous commit is still correct — it prevents the
spurious exception when the projection optimization IS running (as in
the 04004 test).

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

… optimization

The exact count optimization that bypasses `max_rows_to_read` requires
`optimize_use_projections = 1`. Set it explicitly so the test works even
when CI randomizes it to false. Also add `SELECT *` queries to verify
that non-count queries still fail fast with `TOO_MANY_ROWS`.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

…jections`

The exact count optimization code path in `getAggregateProjectionCandidates`
requires `can_use_minmax_projection` to be true before it will set
`only_count_column`. This flag depends on `optimize_use_implicit_projections`.

When CI randomizes `optimize_use_implicit_projections = false`, the function
returns early (no implicit projections + no explicit aggregate projections),
and the exact count optimization never runs. The count query then hits
`max_rows_to_read` and throws `TOO_MANY_ROWS`.

Also add a dedicated regression test for the original issue (#100129).

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

…ct-count-projection

…ct-count-projection

…ary-granule reads

The exact count optimization still needs to read boundary granules at
range edges. With `index_granularity = 128` and a BETWEEN condition
spanning two boundaries, 256 rows of boundary granules need to be read.
The previous `max_rows_to_read = 100` was too low, causing execution-time
`TOO_MANY_ROWS`.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

…ct-count-projection

…ct-count-projection

…ct-count-projection

…oss multiple parts

Addresses review feedback: adds a dedicated stateless test that exercises
`SELECT count()` with `max_rows_to_read` / `force_primary_key` when data is
split across multiple parts with non-aligned granule boundaries. Before the
fix in this PR, this would throw `TOO_MANY_ROWS`.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

…ct-count-projection

The `SELECT *` without a WHERE clause throws `INDEX_NOT_USED` instead of
`TOO_MANY_ROWS` when `force_primary_key` is set. Add a WHERE on the
primary key that covers all rows so the query reaches the row limit check.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

…ct-count-projection

…ct-count-projection