Table notification CREATE/UPDATE can fail under concurrent modification without retry

When Polaris handles an external table notification (CREATE/UPDATE), creating or updating the table entity can fail under a concurrent modification, and there is currently no retry. updateTableLike fails with a concurrent-modification conflict, and createTableLike fails when the entity was created concurrently, so the notification just errors out instead of retrying. A naive retry of the same write would not help, because the entity is read once from the request-scoped resolution view and its version becomes stale. A correct fix needs to re-read the current entity on each attempt, re-apply the new metadata location and timestamp, and retry with a bound. I wanted to discuss the approach before raising a PR: would a retry scoped to the update path be acceptable as a first step, with the create-then-update race handled as a follow-up? And is there an existing retry helper you would prefer to reuse? Location: runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/IcebergCatalog.java (sendNotificationForTableLike).