test: pin the peek row iteration limit to one worker

The limit is enforced per worker, so a multi-worker cluster walks the same
rows a share at a time and no single walk reaches it. That made the
assertion depend on the cluster's worker count, and it made the one-shot
query disagree with the indexed view --auto-index-selects wraps it in: the
view holds only the three rows the LIMIT produced, spread across workers,
so it answered where the one-shot query raised. Pin the block to a
single-worker cluster, which is what max_result_size.slt already does for
the same reason.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: antiguru

test/sqllogictest/persist-fast-path.slt

@@ -245,6 +245,17 @@ ALTER SYSTEM RESET enable_compute_peek_response_stash
 COMPLETE 0
 
 # Persist-backed peeks enforce the same row iteration limit.
+#
+# The limit is per worker, so this needs a single-worker cluster to be
+# deterministic. Spread across several workers the same rows are walked a share
+# at a time and no single walk reaches the limit, which also makes a one-shot
+# query disagree with the indexed view --auto-index-selects wraps it in.
+statement ok
+CREATE CLUSTER peek_iteration_limit_cluster SIZE 'scale=1,workers=1'
+
+statement ok
+SET cluster TO 'peek_iteration_limit_cluster'
+
 simple conn=mz_system,user=mz_system
 ALTER SYSTEM SET enable_compute_peek_row_iteration_limit TO true;
 ----
@@ -280,6 +291,9 @@ ALTER SYSTEM RESET enable_compute_peek_row_iteration_limit;
 ----
 COMPLETE 0
 
+statement ok
+RESET cluster
+
 # The Persist fast path does not apply when an index exists.
 
 statement ok