Core: Validate format version compatibility client-side on REST table create

[nssalian]

Rationale for the change

#17500 added RCK coverage for variant columns following up with the client side change here.

The REST client previously forwarded the CreateTableRequest to the server without validating the schema against the requested format version. So the rejection of a v3-only type (variant, timestamp_ns, geometry/geography, unknown, non-null defaults) on a lower format version depended entirely on the server, and the server's error message is not spec-defined. That is why the RCK cannot assert on it.

Non-REST catalogs already run this check locally via TableMetadata.newTableMetadata -> Builder.build() -> Schema.checkCompatibility. This PR makes the REST client do the same, so the failure and its message are the client's, before any request is sent.

Changes

• TableMetadata.checkFormatVersionCompatibility(schema, properties): resolves the requested format version (default v2) and runs the existing Schema.checkCompatibility. The DEFAULT_TABLE_FORMAT_VERSION constant stays package-private.
• RESTSessionCatalog.create() and stageCreate(): call it before building the CreateTableRequest, so an incompatible schema is rejected client-side with the well-defined "... is not supported until v3" message and no request is issued.
• TestRESTCatalog.testCreateV2TableWithVariantColumnFailsClientSide: asserts the IllegalStateException message AND that no create-table POST reaches the server (the assertion that fails if the client-side check is removed).

Notes

• Replace paths (replaceTransaction) already build TableMetadata client-side and are unaffected.
• The existing CatalogTests.testCreateV2TableWithVariantColumnFails continues to cover the message/behavior; the new REST-specific test adds the client-side-rejection guarantee.

[amogh-jahagirdar]

I don't think I'd add this public utility, at least for now, until we really have multiple callers, and know what appropriate input would be for a whole "formatVersionCompatibility" check. Right now it's just doing schema and properties, and Schema.checkCompatibility is doing the heavy lifting, and the properties is only used to extract the format version.

Think I'd reccomend just inlining this above in the RestSessionCatalog#create call