Let the base58 cancellation budget span a whole block of values - #119388

A 1025-byte conversion accumulates about 0.68 of the work between two checks, so
with a count of its own it reaches none: eight such values in a row invoke the
callback zero times. The test pins that, then pins the five calls the same eight
values make when the caller owns the count, for encode, for decode, and for
values rejected at their last character, where the work is charged from inside
the loop that then returns empty.

The two zero arms are what make the fives meaningful. They rule out one value
being large enough to check on its own, so the test cannot be satisfied by
shrinking the interval instead of keeping the count alive across values.

It is a unit test rather than a SQL one because both a fixed and an unfixed build
raise the same TIMEOUT_EXCEEDED with the same message text for such a block, and
only the elapsed value differs, so an SQL oracle would have to be a wall-clock
bound. The uninterruptible stretch here is memory-bound at about 10 ms per MB of
block, which puts a two-sided margin at roughly 620 MB, and timing-prone
cancellation tests of that shape were removed from master in d5bc955.

The row-loop threading through executeImpl is not covered here, since the
conversions are called directly. It stays covered by review and by the
end-to-end measurement quoted in the pull request description.

Related: ClickHouse#112203

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The existing arm calls encodeBase58 and decodeBase58 directly and keeps the count
itself, so it pins the conversions but not the row loops above them, which are
where a query's block is converted. Those loops are public static functions whose
cancellation callback is a plain std::function, so one can be driven from a unit
test with no clock, no server and no query context: build a column, call the loop
once, count the callbacks.

Eight rows of 1025 bytes invoke the callback five times in each direction, the
same five the same eight values make at the primitive level. Making either loop
give each row a fresh count, which is the behaviour before the count moved to the
caller, drops that to zero and reds this test while all ten of the primitive
tests stay green.

This supersedes the closing note of the previous commit: the loops that convert a
block of String or FixedString values are covered here, and the measurement
quoted in the pull request description now only stands in for the single counter
executeImpl declares, whose scope no unit test can enter, because the callback
does not exist without a query context. Passing the count by value there is not
observable either way: executeImpl calls one loop once per block, so a copy still
spans the block and its value after the call is unused.

Related: ClickHouse#112203

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The header paragraph says in three lines what it said in four, and the note in
encodeBase58 drops a sentence about the reference keeping every exit path
correct: that function has no early return below the binding, so the sentence
described the decoder instead, where it is kept.

Code is unchanged: stripping comments from both revisions of either file leaves
identical text.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>