feat(knn): let a caller rebuild a batch KNN node with a new k

[hamersaw]

What

Adds KNNVectorDistanceExec::with_k(k), returning the node rebuilt with a different per-query k.

Why

A batch KNNVectorDistanceExec bounds every query's candidates by its own k and carries no enclosing top-k SortExec — the plan is just KNNVectorDistance(queries=N, k=K) over a scan. A downstream rewriter that wants to widen the candidate set has nothing to move, and it can't rebuild the node either: try_new_batch is pub(crate) and retain_vector is a private field.

k feeds only the execute-time cut (execute_batch's BatchKnnConfig), never the schema or plan properties, so with_k carries the rest of the node over unchanged. Zero k on a batch node is rejected, matching try_new_batch.

This is the brute-force counterpart to the ANNIvfBatchExec accessors added in #9262. Sophon's WAL union over-fetches the base arm so a block-list can drop superseded rows and still leave ~k live ones; on the indexed batch shape it rebuilds ANNIvfBatchExec, and on the unindexed batch shape it currently can't reach the cut at all.

Testing

test_batch_with_k_rebuilds_the_cut_and_keeps_the_schema covers the widened k, the preserved schema/query_count/is_batch, that the original node is left alone, and the zero-k rejection.

🤖 Generated with Claude Code

[lance-gatekeeper]

✅ Gate recommendation: approve.

This focused builder changes only the batch node per-query candidate bound while preserving its child, schema, distance bounds, vector-retention mode, and plan properties. It retains the constructor zero-k validation and resets execution metrics for the rebuilt node.