exact_rows_before_limit wrong for numbers/primes/generate_series with LIMIT

Run the provided numbers(300) LIMIT 5 SQL reproducer with exact_rows_before_limit = 1, then inspect shouldPushdownLimit in src/Processors/QueryPlan/numbersLikeUtils.cpp and the limit handling in src/Processors/QueryPlan/Optimizations/optimizePrimaryKeyConditionAndLimit.cpp. Compare the behavior with limitPushDown.cpp and a MergeTree query. Done means numbers, numbers_mt, generate_series, and primes report the full pre-LIMIT count while still returning the limited rows.

Describe what's wrong

• rows_before_limit_at_least equals the LIMIT value instead of the true source row count.
• Triggered by SELECT number FROM numbers(300) LIMIT 5 with setting exact_rows_before_limit = 1.
• Expected rows_before_limit_at_least: 300, actual returns 5.
• MergeTree tables report the correct value for the same query shape, so results disagree by source type.

Root cause: shouldPushdownLimit in numbersLikeUtils.cpp has no check for exact_rows_before_limit/alwaysReadTillEnd, so ReadFromSystemNumbersStep caps generation at the LIMIT and the counter never sees the remaining rows; optimizePrimaryKeyConditionAndLimit.cpp has the same missing guard that limitPushDown.cpp already applies.

Does it reproduce on most recent release?

Yes — confirmed on current master (commit 827b4f0e149c6).

How to reproduce

Run with SETTINGS exact_rows_before_limit = 1 and compare against the same query over a MergeTree table or a UNION ALL of numbers.

▶ Run on ClickHouse Fiddle

-- Test: exact_rows_before_limit must report the full pre-LIMIT row count for numbers().

SELECT number FROM numbers(300) LIMIT 5
FORMAT JSONCompact
SETTINGS exact_rows_before_limit = 1, output_format_write_statistics = 0;

Note: an automated re-run of this exact block on current master (827b4f0e149c) did not show the failure; the analyst's run did (outputs below). Environment or ordering may matter.

Expected behavior

With exact_rows_before_limit set, rows_before_limit_at_least should reflect the full pre-LIMIT row count, reading all source rows if needed.

Expected output of the reproducer above:

{
	"meta":
	[
		{
			"name": "number",
			"type": "UInt64"
		}
	],

	"data":
	[
		[0],
		[1],
		[2],
		[3],
		[4]
	],

	"rows": 5,

	"rows_before_limit_at_least": 300
}

Error message and/or stacktrace

The LIMIT is pushed into the source generator, which stops early, so rows_before_limit_at_least equals the LIMIT.

Actual output of the reproducer above on master (827b4f0e149c6):

{
	"meta":
	[
		{
			"name": "number",
			"type": "UInt64"
		}
	],

	"data":
	[
		[0],
		[1],
		[2],
		[3],
		[4]
	],

	"rows": 5,

	"rows_before_limit_at_least": 5
}