Stop the pruning index build when a query cancels

[robinskil]

Parent: #481

Describe the bug

candidate_filter builds the pruning index on tokio::task::spawn_blocking.

Tokio cannot cancel a blocking task. The blocking pool runs it to the end.

A client cancels a query during the pruning pass. The index build continues. No query reads the result.

Impact

The index build is pure CPU work. It pivots one row per dataset into typed Arrow columns.

A collection holds up to millions of datasets. So the wasted CPU time is real.

The build holds a blocking pool thread. Other queries wait for that thread.

Expected behavior

A cancelled query stops the pruning index build.

Suggested fix

1. Pass a cancellation token into build_index.
2. Test the token per group of rows.
3. Return early when the token is set.

An early return needs no new error path. candidate_filter already falls back to CandidateFilter::KeepAll.

Check PruneCache too. moka::future::Cache::try_get_with coalesces the callers of one key. Confirm that a dropped caller does not poison the entry for the others.

Why the code blocks

The choice is deliberate. A million-row pivot must not run on the async runtime.

Keep spawn_blocking. Add the token. Do not move the work back onto the runtime.

File

beacon-db/beacon-file-formats/beacon-arrow-atlas/src/datafusion/pruning.rs

Scope

Atlas only. No other format builds a pruning index this way.

Metrics

atlas_prune_time reports the cost of this pass. atlas_index_rows reports the rows it covers. Both are in datafusion/metrics.rs.