OPTIMIZE on a Glue Iceberg table can drop a commit that lands while it is publishing #2733

Describe the bug

OPTIMIZE on a Glue Iceberg table can drop a commit that lands while it is publishing.

Bin-pack compaction re-reads Glue's metadata_location and aborts if that file changed during the rewrite. It then writes the new metadata and calls catalog->updateMetadata. Glue's UpdateTable replaces metadata_location and does not check the snapshot. Any commit that lands after that re-read and before UpdateTable returns is no longer the current snapshot.

This is specific to Glue. A REST catalog rejects the update with assert-ref-snapshot-id and does not move the catalog pointer.

To Reproduce

Needs a Glue Iceberg table with at least two small data files, so OPTIMIZE rewrites them. The insert has to land after OPTIMIZE has rewritten the files and re-read metadata_location, and before Glue UpdateTable returns.

1. Session A:

OPTIMIZE TABLE glue_db.events
SETTINGS allow_experimental_iceberg_compaction = 1;

2. Session B, in that window:

INSERT INTO glue_db.events VALUES (1, 'new');

3. After session A finishes, read the table through Glue:

SELECT count() FROM glue_db.events WHERE note = 'new';

Expected behavior

The count is 1. The insert remains in the current snapshot.

Additional context

Related: #2420