Pin that the byte budget still applies when the row limit is unlimited

The two arms added with the fix could not distinguish it from an implementation
that ignores `max_joined_block_size_bytes` whenever `max_joined_block_size_rows`
is `0`. Arm 1 sets a 4 MiB budget the 1000-row result cannot reach, so its "one
block" assertion holds either way, and arm 2 constrains only the rows axis. The
changelog entry promises the byte budget is honoured in exactly that case, and
nothing asserted it.

Add a third arm with a budget that does bite: 4500 bytes gives blocks of 100
rows, against 10 before the fix and 1000 for the whole result. On a mutant that
keeps the sentinel change but ignores the byte budget, this arm is the only one
in the suite that reddens, and the two halves of its range are separately live:
the pre-fix binary fails the lower bound at 10, the mutant fails the upper bound
at 1000.

The bound is a range rather than an exact count because `avg_bytes_per_row`
(`HashJoinResult.cpp:440`) sums container capacities rather than payload sizes,
so the quotient is build-dependent and there is no deterministic block size to
assert. The two existing arms keep their exact values, which do not depend on
that quotient.

Drop `no-parallel-replicas`. The only source here is `numbers()`, which plans as
`ReadFromSystemNumbersStep`, while `collectReadsToDistribute` collects only
`ReadFromMergeTree` nodes and `insertParallelReplicasSplit` returns early on an
empty set (`applyParallelReplicas.cpp:464-474`, `:552`, `:569-571`), so no split
step is ever inserted and the tag protected nothing. It did cost coverage:
`clickhouse-test` skips a tagged test in dedicated parallel replicas runs. 9 of
50 randomized runs injected the parallel replicas settings, and all 50 passed.