fix: writer starvation in DatasetConsistencyWrapper

[emilk]

Summary

• Fix writer starvation caused by get_mut() acquiring a read lock (via reload()) before requesting the write lock, which prevented tokio's RwLock write-fairness from protecting the writer
• get_mut() now acquires the write lock first, then reloads under that lock via a new reload_under_write_lock() helper

Problem

DatasetConsistencyWrapper uses a tokio::sync::RwLock, which is write-fair: once a writer is waiting, no new readers are admitted. However, get_mut() called reload() before requesting the write lock, and reload() itself acquires a read lock to check the current version. This meant the writer was competing as a reader during the reload phase, so tokio never saw a pending writer and its fairness guarantee never kicked in.

Under high read concurrency, writers could starve indefinitely; each time the writer's reload() read lock was released, new readers would slip in before the subsequent .write().await could be served.

Fix

Restructure get_mut() to acquire the write lock first, then perform the reload under that exclusive lock. This ensures tokio's write-fairness blocks new readers as soon as a writer calls get_mut(). The read path (get()) is unchanged and still uses the optimistic read-lock-first strategy.

[github-actions]

ACTION NEEDED
Lance follows the Conventional Commits specification for release automation.

The PR title and description are used as the merge commit message. Please update your PR title and description to match the specification.

For details on the error please inspect the "PR Title Check" action.