The inner fill loop of resizeConstantSize / resizeDynamicSize did not
poll cancellation, so a single call resizing to ~1e9 elements would
keep running long past max_execution_time or KILL QUERY. Add a static
CurrentThread::throwIfQueryCancelled helper and poll it every 1024
iterations inside both resize variants. Migrate the existing inline
caller in MergeTreeIndexVectorSimilarity to the helper.

Stuck-thread symptom seen here:
https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=104823&sha=9df07df5a0a2f94ea2ee509d2fef72b5c1b01a5d&name_0=PR&name_1=Unit%20tests%20%28asan_ubsan%2C%20function_prop_fuzzer%29

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

… time limit directly

Two changes to make `CurrentThread::throwIfQueryCancelled` cover the in-function
polling cases that the previous version missed:

- Invoke `Context::interactive_cancel_callback` from the polling site. Without
  this, TCP `Cancel` packets sent mid-query (Ctrl-C in clickhouse-client) only
  reach the server when the pipeline executor next ticks, which for
  long-running function calls can be many seconds. Throttled to at most once
  per `interactive_delay` per thread so it doesn't flood the wire.
- Use `QueryStatus::checkTimeLimit()` instead of `throwIfKilled()`. The former
  enforces both `is_killed` and the elapsed-time limit directly, so polling is
  responsive even when `CancellationChecker` is slow to flip `is_killed`. This
  is what the previous fast-test failure on PR ClickHouse#104875 hit: the deadline never
  fired, polling never saw `is_killed`, and the resize ran to natural
  completion.

Adds `tests/queries/0_stateless/04238_array_resize_cancellation_kill.sh` to
cover the Ctrl-C / TCP cancel path; the existing `04237_*` test already covers
the `max_execution_time` path.

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

…rent invocations

`CurrentThread::throwIfQueryCancelled` now invokes `interactive_cancel_callback`
from arbitrary pipeline worker threads in addition to the executor's wait loop,
so the callback can run concurrently from multiple threads. The TCP variant
already serializes via `callback_mutex`; the local variant did not, racing on
the plain-bool write to `state->is_cancelled` and on the user-supplied
`process_progress_callback`.

Serialize the callback body with a `try_to_lock` mutex: if another thread is
already inside the callback, skip the call (it would do the same work).

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

…lback mutex

The previous commit serialized the interactive cancel callback body but
`LocalQueryState::is_cancelled` was still touched outside that lock by
`LocalConnection::sendCancel`, the destructor, and the pull loop in
`pullBlock`. The race is still live as long as the field is a plain `bool`.

Switch the field to `std::atomic<bool>` so every read/write is race-free
regardless of which thread does the access. The callback-body mutex stays
because it serializes the user-supplied `process_progress_callback`, which
isn't ours to assume thread-safe.

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

Worker threads run multiple queries back-to-back. The previous code kept
`last_callback_at` as a plain `thread_local` so query A's recent poll
could suppress query B's first cancel check for up to `interactive_delay`.

Track the query-context pointer in TLS and treat any change as a reset
of the throttle, so each query gets an immediate first cancel poll.

Addresses ClickHouse#104875 (comment)

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

…absolute index

Previous code used `i % CANCELLATION_CHECK_INTERVAL == 0` where `i` is the
absolute array index, starting at `array_size`. When `length - array_size`
is smaller than the interval and `array_size % interval != 0` (for example
resizing `[x]` to `1001`), the check never fires inside that row's append
phase. With many such rows in a single block, the function spends seconds
without polling and cancellation only fires at the next between-block
check.

Switch to `(i - array_size) % CANCELLATION_CHECK_INTERVAL == 0` at all four
fill loops, so we poll every 1024 appended elements regardless of starting
offset. Same cost, no new state.