feat(python-setup): recover from a constraint conflict with a Retry-as-DB-Connect fallback

[rugpanov]

Why

The uv-native "set up Python environment" Full preset pins the cluster's
dependencies, so uv sync can fail when those pins conflict with the user's own
dependencies. The CLI now emits a distinct E_PROVISION_CONFLICT for that
case (shipped in CLI v1.16.0, already bundled on main). Rather than the
generic E_PROVISION toast ("uv could not resolve the project's dependencies…
adjust your dependencies"), offer a one-click recovery: re-run as DB Connect
(--no-constraints), which drops the conflicting cluster-dependency pins while
keeping matched Python + databricks-connect.

What

• E_PROVISION_CONFLICT — a distinct result-model error code for a genuine
  pin-vs-local conflict (a generic sync failure stays E_PROVISION), with its
  own copy: "The cluster dependencies conflict with your local dependencies, so
  uv sync couldn't resolve the environment."
• Recovery UX (Full-preset conflict only) — the generic toast is replaced
  with Retry DB Connect setup and Open pyproject.toml. "Show Logs" is
  dropped from this self-service toast (the channel is still revealed).
• Restore-then-retry — the conflict fails after the runtime pins were
  merged into pyproject.toml (diskMutated: true, pre-merge file saved to the
  CLI's backupPath). So Retry first restores that backup, then re-runs with
  the dbconnect preset — --no-constraints alone would only stop the retry
  from re-adding pins, not remove those already on disk. The restore is atomic
  (temp sibling + rename) and refuses a backupPath resolving outside the
  project. When backupPath is absent/empty (e.g. a no-op-merge re-run), Retry
  isn't offered and the run falls back to the ordinary doc-link handling.
• Guards — runGuarded/runResolved let the retry re-enter with the
  dbconnect preset directly (no re-prompt), coalesced so a click can't race an
  in-flight run; dbconnect skips constraints so the retry can't loop; a stale
  toast's Retry no-ops once the project is ready.
• Telemetry — a conflict_retry value on the existing
  python_env.setup.attempt trigger dimension marks recovery runs, paired with
  the python_env.setup.result outcome for the recovery success rate. No new
  event. A conflict is never report-worthy (it's the user's own dependencies).

Live against the shipped CLI

Unlike when this was first written, CLI v1.16.0 (on main) emits
E_PROVISION_CONFLICT, so the recovery path is now exercised end-to-end, not
dormant. Note: the CLI only populates backupPath on the first merge; a
re-run over an already-merged pyproject.toml is a no-op merge and returns an
empty backupPath, in which case the run correctly falls through to the generic
path (the truthy-backupPath guard).

Testing

• test:unit: new coverage for the conflict copy + fallback doc link, the
  run-action dispatch, openProjectFile, the controller conflict→retry flow
  (restore-before-retry ordering, --no-constraints + adopt on success,
  conflict_retry telemetry paired with its outcome, open pyproject at the run's
  cwd, reportOffered: false, missing/empty-backupPath and non-Full fallbacks,
  restore-failure aborts without a retry attempt), and the atomic/in-project
  restore wiring.
• tsc + eslint + prettier clean on changed files.

Supersedes #2181, which merged into the (now-defunct) preset-picker branch rather
than main.

This pull request and its description were written by Isaac.

[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: 2186
• Commit SHA: 5e67299046dfab1ea30148396ab4ab40c8d1fadc

Checks will be approved automatically on success.

[rugpanov]

🤖 Integration tests running for 5e672990 — ⏳.
View run