Do not read the max_joined_block_size_rows sentinel as a zero budget

Both `max_joined_block_size_rows` and `max_joined_block_size_bytes` are
documented as `0 means unlimited` (`src/Core/Settings.cpp:283-288`). In
`numLeftRowsForNextBlock` the rows sentinel was loaded as a plain budget and
passed to `std::min`, which reads `0` as the tightest limit. `max_rows` became
`0`, so `next_allowed_offset` equalled `prev_offset`, the binary search returned
the first offset past `prev_offset`, and the `std::max(..., 1)` floor pinned the
result at exactly one left row per output block. The pre-existing early return
covers only the case where both limits are zero, so setting just the rows limit
to its documented "unlimited" spelling produced the worst possible blocking.

Apply each limit only when it is set, which is the idiom already used for this
same setting pair in the sibling `ConstantJoin` (`ConstantJoin.cpp:621-629` and
`:672-681`). 13 of the 14 readers of the sentinel in `src/` already normalise
it; this closes the last one. Normalising to `SIZE_MAX` instead was rejected
because `prev_offset + max_rows` would then overflow.

Measured with 10 keys and 100 rows per side, 100000 output rows:
`max(blockSize())` was 100 across 1000 blocks before and 100000 in a single
block after, with identical row counts, so this was never a wrong-results bug.
All five combinations of the two settings were measured on both binaries and
only `rows == 0 && bytes > 0` changes; the default path and the other four are
bit-identical. No setting default changes.

The `= 0` spelling had no coverage because the existing
`03567_max_joined_block_size_bytes.sql.j2` expresses "no row limit" as a large
number instead. The new test pins `joined_block_split_single_row = 0`, which is
a precondition rather than a workaround: that setting is rejected outright with
`NOT_IMPLEMENTED` when the row limit is zero (`HashJoin.cpp:220-224`), and the
test runner randomises it.

Introduced in ef15e7af7751de95a3959b326876268887281e37.

Closes: https://github.com/ClickHouse/ClickHouse/issues/102007