fix: reject CreateIndex when concurrent RewriteColumns modified indexed fields

[zehiko]

What

When a MergeInsert updates fewer columns than the dataset schema, Lance takes the RewriteColumns path — rewriting column data files in-place within the same fragment (same fragment ID, same row IDs, different column values). If optimize_indices concurrently builds a new index from the pre-update data and commits it, the conflict resolver in check_create_index_txn unconditionally allows it ("row ids are still valid"). The resulting index has stale values for the rewritten columns.

Since the fragment ID didn't change, effective_fragment_bitmap does not filter it out, and the stale index data is authoritative. Indexed scans then return incorrect results while full scans return correct data.

The fix: when CreateIndex encounters a concurrent Update with RewriteColumns mode, check whether the modified fields overlap with the new index's fields AND whether the rewritten fragments are in the index's fragment_bitmap. If so, return a retryable conflict, forcing optimize_indices to re-read the updated data.

RewriteRows (full-column upsert) and Delete operations remain unconditionally allowed — they remove the old fragment entirely, so effective_fragment_bitmap naturally filters out stale entries.

Upstream PR: lance-format#6493

Testing done

• new unit tests
• ran small repro test - 90% failure before, 0 failures after
• ran our integration test (that triggered the whole investigation), before we were seeing 15-20% failure, now no failures (300 runs)

[andrea-reale]

amazing!