Environment-aware catalog handling for cross-environment dataset promotion

What is the problem or goal you're trying to solve or accomplish?

Customers who promote datasets between isolated environments (e.g. Prod-Support → Production) using the export/import utility have no built-in way to handle environment-specific values during import. The catalog field is the concrete pain point: it is a dataset property, so a dataset import overwrites it verbatim from the source bundle. When the source and target environments deliberately use different Postgres catalog (database) names, every imported dataset is left bound to the source environment's catalog.

Two consequences for the customer:

First, a correctness/validation gap — already filed separately as a bug — where, if the target connection has allow_multi_catalog disabled, the import accepts the non-default catalog with no validation and queries silently execute against the wrong database. That bug's fix is to make the import fail loudly.

Second, and the subject of this FR: even with that validation fix in place, the import will only reject a mismatched bundle, not resolve it. The customer still has no first-class way to promote datasets across environments that differ by catalog. Today their only options are manual ZIP editing or a customer-owned find-and-replace/templating step before import.

The goal: make cross-environment dataset promotion a seamless, supported workflow without requiring users to manipulate export archives outside the platform.

How are you solving it currently?

Interim, customer-side, until the validation bug ships and pending this FR:

• A find-and-replace pass over the catalog: field in every dataset YAML inside the export ZIP before import (scriptable; Support has supplied a script).

• Or, for teams with a deployment pipeline, treating the dataset YAMLs as version-controlled templates with catalog parameterized and rendered per target environment before the bundle is imported.

What is your recommended solution?

Provide a supported, in-platform mechanism for resolving environment-specific values during dataset import. Options for Product to weigh, in rough order of preference:

1. Explicit catalog mapping at import time. Surface an optional source-catalog → target-catalog mapping step in the import flow (UI and API), analogous to the existing password prompt for database connections. The operator confirms the mapping; the resolution is explicit and reviewable. This addresses the customer's workflow need without the platform silently altering an asset.

2. Documented templating support. Officially support and document parameterized dataset YAMLs (e.g. a placeholder for catalog) rendered at import time from operator-supplied or environment-derived values, making the BI-as-code pattern a first-class, documented path rather than an undocumented workaround.

3. Automatic catalog resolution to the target default (customer's original request). Have the import silently rewrite a non-permitted catalog to the target connection's default. Recorded here because the customer explicitly proposed it, but flagged with a known objection from Support engineering: this makes the import override a primary property of the imported asset without operator awareness, trading one silent behavior for another. Not recommended as the default, but included for completeness.