fix(console): allow setting connection-type-specific fields on EXTERNAL catalogs

[yj-lee0503]

Problem

The create-catalog form supports EXTERNAL catalogs but collects none of the connection-type-specific fields, because ConnectionConfigInfo in console/src/types/api.ts mirrors only the spec's base schema:

Connection type	Missing field	Declared on
ICEBERG_REST	remoteCatalogName	IcebergRestConnectionConfigInfo
HADOOP	warehouse	HadoopConnectionConfigInfo
HIVE	warehouse	HiveConnectionConfigInfo

All three are selectable in the form. The server accepts the resulting catalog, so the failure is deferred to first use rather than surfacing at create time.

For ICEBERG_REST the consequence is concrete: the spec describes remoteCatalogName as translating "into a 'prefix' added to all REST resource paths", so a prefix-scoped remote rejects the proxied request and namespace listing returns 400.

The Iceberg REST federation docs document this as user-facing configuration — "supply it when the remote server multiplexes multiple logical catalogs under one URI" — and the CLI exposes it as --iceberg-remote-catalog-name. The console is the only surface that cannot set it.

Reported in #266, which has the reproduction.

Change

Adds both fields to the flattened ConnectionConfigInfo, following how StorageConfigInfo handles the S3/Azure/GCS discriminator in the same file, and renders them conditionally on the selected connection type.

Connection type is checked in two places, for different reasons. Rendering is gated so a field only appears for the types it applies to. The payload builder filters by type as well as presence, because react-hook-form retains values for unmounted fields by default, so a name typed under ICEBERG_REST would otherwise be submitted after switching to HADOOP.

The details page guards on presence alone. The discriminator means a response for one connection type cannot carry another's field, so a type check there would exclude nothing.

Both fields are optional and nothing existing changes behavior; the diff is additive.

Testing

make lint and make build (which covers format-check) are clean.

Verified against a live Polaris 1.5.0: a federated catalog created with remoteCatalogName set resolves and lists namespaces, where the same catalog without it returns 400. That was done through the management API, so it confirms the server behavior and the payload shape rather than the browser interaction.

HADOOP and HIVE are compile-and-render only; I have no such remote to test against. Both take the same code path as ICEBERG_REST apart from the field name.

Notes

• No spec change needed. All three subtypes already declare these fields.
• EditCatalogModal is untouched deliberately. UpdateCatalogRequest accepts only currentEntityVersion, properties, and storageConfigInfo, so a field there would be a control that does nothing. This differs from the storage field proposed in Console: add kmsUnavailable option for S3 catalogs #261, which the edit modal can handle.
• Flattened rather than discriminated. Proper subtypes would be more faithful to the spec, but StorageConfigInfo in the same file is flattened, so this follows the local convention. Happy to rework if you would rather change the pattern.
• Connection config cannot be edited after creation, and that is a server constraint rather than a console gap: UpdateCatalogRequest does not accept connectionConfigInfo at all. uri and the auth fields already had this limitation; these two inherit it.
• The unused icebergRemoteCatalogName / hadoopWarehouse on CreateCatalogRequest (api.ts:83-84) are left alone. They sit flat on the catalog object rather than under connectionConfigInfo, are never assigned, and cover only two of the three types. Removing them is a separate cleanup.
• The spec marks ConnectionConfigInfo experimental; that applies equally to the existing uri and authenticationParameters fields.