Fix stale snapshot detection to return 409 instead of 400

[cbb330]

Summary

• Fix stale snapshot detection during concurrent modifications to return HTTP 409 (Conflict) instead of HTTP 400 (Bad Request)
• Reclassify ValidationException with stale snapshot message to CommitFailedException (409) to allow client retry
• Ensure other ValidationException instances are handled as HTTP 400 Bad Request responses (e.g., attempting to delete a non-existent snapshot)

Problem

When concurrent modifications occur during a transaction commit:

1. Client builds snapshots based on table version N (e.g., lastSequenceNumber = 4)
2. Client sends commit request with these snapshots in SNAPSHOTS_JSON_KEY
3. Meanwhile, another process commits version N+1 (e.g., lastSequenceNumber = 5)
4. Server calls doRefresh() which updates current() to version N+1
5. Bug: The snapshots in SNAPSHOTS_JSON_KEY are now stale (their sequence numbers are based on version N)
6. Iceberg's TableMetadata.addSnapshot() throws ValidationException → mapped to 400 Bad Request
7. Should return 409 Conflict so clients know to refresh and retry

Solution

Let Iceberg's existing validation detect sequence number conflicts, then catch the ValidationException and reclassify it as CommitFailedException for the specific stale snapshot error pattern:

} catch (ValidationException e) {
  // Stale snapshot errors are retryable - client should refresh and retry
  if (isStaleSnapshotError(e)) {
    throw new CommitFailedException(e);
  }
  throw new BadRequestException(e, e.getMessage());
}

This approach is simpler than pre-checking and leverages Iceberg's existing validation.

Test Plan

• Unit test testStaleSnapshotErrorDetection() verifies error detection logic
• All existing internalcatalog tests pass
• Integration testing in staging environment

[sumedhsakdeo]

LGTM. Thanks @cbb330

[teamurko]

Thank you @cbb330! Looks good, asking for a test