fix: handle empty batch from deletion in add_columns_from_stream

[zhangyang0418]

What

Fixes a panic in add_columns when a fragment's deleted rows fill an entire read batch.

Closes #7232.

Root cause

In add_columns_from_stream, the updater reads each fragment in physical batches and applies the deletion vector via filter_record_batch. When every row in a physical batch is deleted, the filter yields a 0-row batch. The outer loop then sets rows_remaining = 0, the inner while rows_remaining > 0 loop never runs, batches stays empty, and concat_batches(&batches[0].schema(), ..) panics with index out of bounds: the len is 0 but the index is 0.

This was hit in production using a merge-columns workflow over a dataset whose fragment had a deletion file, where the deleted rows happened to align with a read-batch boundary.

Fix

When the updater yields a 0-row batch, feed an empty batch back to the updater (to keep it in sync) and continue:

if rows_remaining == 0 {
    updater.update(RecordBatch::new_empty(stream.schema())).await?;
    continue;
}

Test

Adds test_add_columns_with_fully_deleted_batch: writes a single fragment with 105 rows, deletes the trailing 5 rows so that — read with batch_size=50 — the last batch [100..105) is fully deleted, then verifies add_columns succeeds and the new column has the correct values. The test panics on the unpatched code and passes with the fix.