fix: guard table rename against concurrent commits

[mkuchenbecker]

Summary

TLDR. A table rename could silently overwrite a committed snapshot. The rename database update is now conditional on the HTS row version, so a rename that loses the service read-to-update race returns HTTP 409 instead of overwriting the winning commit.

UserTableHtsJdbcRepository.renameTableId previously issued an unconditional JPQL update without a version predicate or version increment. When a rename raced a snapshot commit, it could overwrite the winner's metadataLocation and report success.

This change:

• Makes the rename update conditional on the current @Version and increments the version atomically.
• Threads the caller's expected metadata location from the internal catalog to HTS.
• Maps stale tokens and zero-row updates to EntityConcurrentModificationException and HTTP 409.
• Converts the HTS conflict back to CommitFailedException, preserving Iceberg's existing retry behavior.
• Adds repository, service, controller, internal-catalog, and fixture coverage for stale tokens and forced race interleavings.

The new expectedMetadataLocation query parameter is optional for HTTP compatibility. Updated catalog callers supply it, while tokenless callers retain the row-version guard across the HTS service read-to-update interval.

Changes

• Internal API Changes
• Bug Fixes
• Tests

Testing Done

• Added repository coverage for version-qualified rename updates.
• Added service coverage for stale caller tokens and forced concurrent commits.
• Added controller and internal-catalog propagation coverage.
• Upstream pull request validation

Additional Information

• Breaking Changes
• Deprecations
• Large PR broken into smaller PRs, and PR plan linked in the description.