SQL UDF REST catalog write support (once standardized)

[rraulinio]

Summary

This is a follow-up to #1360.

iceberg-go now has the foundation for SQL UDF catalog support:

• Add SQL UDF metadata model package #1418 adds the spec-validated udf metadata model and metadata builder.
• Add SQL UDF REST catalog read support #1432 adds the REST catalog read side for listing and loading functions.

The current Iceberg REST OpenAPI defines only the read-side function operations:

• GET /v1/{prefix}/namespaces/{namespace}/functions
• GET /v1/{prefix}/namespaces/{namespace}/functions/{function}

The OpenAPI does not currently define standardized function write routes or request/response contracts for operations such as create, replace/update, drop, or commit. The REST spec change that introduced list/load support was intentionally scoped as read-only Stage 1 and deferred function CRUD to a follow-up proposal: apache/iceberg#15180.

The udf metadata builder can construct valid immutable metadata, but a REST client still needs a standardized catalog protocol for publishing that metadata and atomically changing the catalog's current metadata pointer. Until that protocol exists, iceberg-go should not introduce implementation-specific REST routes or wire models that may diverge from the eventual Iceberg contract.

Desired outcome

Once the Apache Iceberg REST catalog specification defines function write operations, add the corresponding generic client support to iceberg-go using the standardized contracts.

The implementation should, as applicable to the final specification:

• expose write operations through an optional catalog capability interface, consistent with existing iceberg-go catalog patterns
• add the standardized endpoint constants and honor endpoint discovery through ConfigResponse.endpoints
• implement the exact request and response wire models from the REST OpenAPI
• use the existing udf metadata model and builder rather than introducing a second metadata representation
• preserve the specification's atomic metadata update and overload/version-history semantics
• map standardized errors for missing namespaces/functions, already-existing functions, conflicts, invalid requests, and unsupported operations
• implement any specified concurrency controls, preconditions, and idempotency behavior
• add unit coverage for successful writes, validation failures, error mapping, endpoint negotiation, concurrent/conflicting updates, and round-tripping written metadata through LoadFunction
• add documentation and examples for the supported catalog operations

The public Go API should be designed from the final standardized operations rather than assuming in advance that the REST surface will use a particular set of create/replace/drop methods.

[rraulinio]

@laskoviymishka @zeroshade Please assign to me. I'll keep an eye on things and implement this later. Thank you!