[FLUSS-3483][coordinator] Validate lake snapshot offsets before commit

[Jackeyzhe]

Purpose

Linked issue: close #3483

This PR fixes a race where a stale V2 lake snapshot commit can be accepted after a table is dropped and recreated. In that case, the recreated table may get a /laketable znode pointing to an offsets metadata file generated for the old table id, causing lake tiering to repeatedly fail when reading the stale offsets path.

Brief change log

• Reject V2 lake snapshot commits when the target table id no longer exists or is queued for deletion.
• Validate the V2 lake snapshot offsets metadata before writing it to ZK:
  • the offsets file must be readable;
  • the file-level tableId must match the commit table id;
  • every TableBucket in the offsets file must also belong to the commit table id.
• Validate both tiered offsets and readable offsets metadata paths when they differ.
• Add regression coverage for:
  • non-existent table id commits;
  • table queued for deletion;
  • recreated table id with stale offsets metadata from the old table id;
  • RPC-level V2 commit after table drop.

Tests

mvn -pl fluss-server -DskipITs -Dcheckstyle.skip -Drat.skip -Dspotless.check.skip=true -Dtest=CoordinatorEventProcessorTest#testCommitLakeTableSnapshotV2RejectsMismatchedOffsetsFileTableId+testCommitLakeTableSnapshotV2RejectsNonExistentTable+testCommitLakeTableSnapshotV2RejectsQueuedForDeletionTable test

mvn -pl fluss-server -DskipITs -Dcheckstyle.skip -Drat.skip -Dspotless.check.skip=true -Dtest=CommitLakeTableSnapshotITCase#testCommitLakeTableSnapshotV2RejectedAfterDropTable test

API and Format

no

Documentation

no