[#12957] fix(lance): Prevent stale schema repair writes

[IcebreakerSA]

What changes were proposed in this pull request?

Reload the complete Lance table repair observation after an optimistic lock conflict instead of retrying with previously read schema data. Before updating metadata, verify that the observed table ID, location, and Lance version still match the current table.

Add deterministic regression tests for concurrent metadata updates and table identity or location changes, plus integration coverage for persisting a newer Lance dataset schema through the catalog API.

Why are the changes needed?

A schema repair can read an older Lance dataset version and later overwrite metadata that already points to a newer version. A version check alone is also insufficient when a table is replaced or its location changes.

Fix: #12957

Does this PR introduce any user-facing change?

No API or property changes. Lance schema repair no longer writes schema metadata from a stale table observation.

How was this patch tested?

• Reproduced the regression against the original implementation, where a version 8 observation overwrote metadata at version 9.
• Added deterministic interleaving tests that change stored metadata while the old dataset schema is being read, then verify the newer stored schema is preserved for version, table identity, and location changes.
• Added an integration test that advances a real Lance dataset schema, loads it through Gravitino, and verifies the updated schema and lance.version remain persisted on a second read.
• Ran the module unit checks and the new integration test on Linux: https://github.com/IcebreakerSA/gravitino/actions/runs/34242053525
• Ran compile and Spotless checks locally with JDK 17.