[MsMansiDhruv]

Closes #4200

Rationale for this change

Currently, \ExpireSnapshots._commit\ determines protected snapshots from the table's loaded metadata and sends no table requirements (\self._requirements = ()). When another transaction concurrently moves or rolls back a branch/tag (such as rolling back \main\ to the snapshot being expired), the expiration commit succeeds and \RemoveSnapshotsUpdate\ silently deletes that ref. In the case of \main, the table completely loses its \main\ branch and reads as empty.

This change adds \AssertRefSnapshotId\ requirements to \self._requirements\ for each ref protecting snapshots. If a protected ref has changed concurrently, catalog validation fails with \CommitFailedException\ instead of removing the ref or leaving the table in an inconsistent state.

Are these changes tested?

Yes, tested via unit and integration tests in \ ests/table/test_expire_snapshots.py:

• \ est_expire_snapshots_asserts_ref_snapshot_id_requirements: verifies that \AssertRefSnapshotId\ is staged for all protected refs.
• \ est_expire_snapshots_concurrent_rollback_fails: end-to-end integration test with \SqlCatalog\ verifying that concurrent rollback onto an expired snapshot fails with \CommitFailedException\ and preserves \main\ and its rows.

Are there any user-facing changes?

No breaking API changes. Concurrent snapshot expiration safely raises \CommitFailedException\ if a protected branch or tag changed during the operation.