Update Databricks CLI to v1.15.0

[eng-dev-ecosystem-bot]

Update Databricks CLI to v1.15.0

[github-actions]

If integration tests don't run automatically, an authorized user can run them manually by following the instructions below:

Trigger:
go/deco-tests-run/vscode

Inputs:

• PR number: 2175
• Commit SHA: e7cd2574cc3fcf19a49d4c81891b30d44308c003

Checks will be approved automatically on success.

[rugpanov]

Executive summary — Databricks CLI v1.14.1 → v1.15.0

CLI — environments setup-local (the surface the extension's Python-setup flow drives)

• Falls back to a compatible already-installed Python interpreter when uv python install fails. (#6457)
• Can now update pyproject.toml files that contain TOML multi-line strings. (#6445)

Bundles (all reached through bundle deploy / bundle summary / bundle init)

• Apps: removed forward_user_access_token from the update mask — fixes a deploy regression introduced in 1.14.1, the exact version this PR replaces. (#6510)
• Terraform→direct migration now runs a deployment plan against the converted state before committing, and abandons the migration if the plan fails. (#6486)
• Direct-engine correctness fixes: duration/timestamp edits like suspend_timeout_duration were silently dropped (#6377); $${...} didn't escape a literal ${...} (#6484, #6489); Lakebase/postgres updates (default_endpoint_settings, pg_settings, expire_time/ttl/suspend_timeout_duration) now deploy (#6440, #6441, #6443); a table_update-triggered job now converges (#6442).
• PyDABs: Resources.add_catalog + catalog_mutator decorator. (#6408)
• Template defaults: serverless environment version 5 + databricks-connect 16.4 (#6378); dbt-sql template classic compute → DBR 16.4 LTS (#6418).

Dependency updates

• Go toolchain → 1.26.8. (#6476) — build-time only.

What could be integrated into the VS Code extension experience

The extension is a thin shell over the bundled CLI (packages/databricks-vscode/bin/databricks), so most of this delta reaches users the moment the binary is swapped, with no extension code change. Ranked by effort-to-value:

1. Just ship the bump — the Apps + direct-engine deploy fixes flow through for free (highest value, zero integration work).
The extension deploys bundles by shelling out to bundle deploy (src/cli/CliWrapper.ts:914) and refreshes state via bundle summary --force-pull (src/cli/CliWrapper.ts:779), where the --force-pull comment notes it deliberately regenerates state so the provider version matches the bundled CLI (src/cli/CliWrapper.ts:796-798). Every fix in the Bundles group — the Apps regression that this PR's outgoing 1.14.1 introduced (#6510), plus the direct-engine Lakebase/postgres/table_update/$${} fixes — is transparent to that code and lands purely by swapping the binary. This is the strongest reason to merge promptly, not an integration task. No-op for extension code; pure runtime win.

2. Optional copy softening for setup-local failures (cleanup, low confidence, ~1–2 strings).
The extension owns bespoke error-mapping for environments setup-local in src/python-setup/utils/errorMessages.ts. #6457's interpreter fallback means E_PYTHON_INSTALL — currently "uv could not install the required Python version for this runtime." (src/python-setup/utils/errorMessages.ts:197-198) — will fire less often, and only after both the uv python install and the new fallback have failed. The copy is still technically accurate when it fires, so this is a marginal wording tweak (e.g. "…and no compatible interpreter was found") rather than a real defect. Cleanup, optional. Similarly, #6445 reduces E_MERGE failures (src/python-setup/utils/errorMessages.ts:195-196) on multi-line-string pyproject.tomls — transparent, no action.

3. Terraform→direct migration warning — already built; the CLI change is mostly transparent (net-new only if you want a one-click action).
BundleEngineManager already reads the engine field off validate output (src/bundle/models/BundleValidateModel.ts:17-19) and, when it's "terraform", shows a deprecation warning linking the migration guide (src/bundle/BundleEngineManager.ts:18-21,81-100). #6486 makes the CLI's automatic migration safer (plan-before-commit), and that safety applies transparently on the next bundle deploy. So the honest read is: nothing is required here. The only integration opportunity would be net-new feature work — promoting the passive warning to an in-editor "migrate now" action — and even that is weakly motivated since the CLI performs the migration itself; I'd hold off.

4. PyDABs / new schema fields — YAML autocomplete auto-updates; the checked-in type does not.
The bundle YAML autocomplete provider fetches the schema live from the bundled binary via bundle schema (src/cli/CliWrapper.ts:582-589, src/bundle/bundleAutocompleteProvider.ts:13), so any new schema surface flows in automatically after the bump. #6408 is a Python API (add_catalog / catalog_mutator), not new YAML, so there's nothing to wire. The generated src/bundle/BundleSchema.ts (which already carries the PyDABs block at ~4859) is a separate, checked-in TS type that only refreshes when regenerated — a routine maintenance chore, not required by this changelog. Effectively auto / no-op.

5. Explicit no-ops for the extension:

• dbt-sql DBR 16.4 template (#6418) and serverless env-version-5 / databricks-connect 16.4 template defaults (#6378) are bundle init template contents; the extension shells bundle init (src/cli/CliWrapper.ts:891) and passes --serverless-version verbatim (src/python-setup/utils/setupLocalArgs.ts:45), so new defaults appear with no code change. Note the extension's own DATABRICKS_CONNECT_VERSION = "13.3.2" constant and its "update to 15.4.0 or higher" message (src/utils/constants.ts:3, src/language/EnvironmentDependenciesVerifier.ts:313) are unrelated to and not touched by this bump — flagging only so no one conflates the template's 16.4 with that constant.
• Go toolchain 1.26.8 (#6476) — build-time only, invisible to the extension.

Mechanics of the bump: update cli.version 1.14.1 → 1.15.0 in packages/databricks-vscode/package.json:1874-1876 and re-fetch the binary (yarn workspace databricks run package:cli:fetch). There is no minimum-CLI-version gate to raise — the only version check is checkBundledCliVersion, which is dev-only and merely warns on a stale binary (src/utils/packageJsonUtils.ts:174-196, gated at :178).

_{🤖 Auto-generated executive summary of the CLI v1.14.1 → v1.15.0 changelog. Integration notes are opportunities, not commitments — verify before acting.}