feat(python-setup): widen conflict recovery to generic uv sync (E_PROVISION) failures

[rugpanov]

What

Widen the Python-setup conflict recovery so a Full-preset run that fails uv sync with a generic E_PROVISION (not only the CLI's provable, pre-sync E_PROVISION_CONFLICT) offers the same recovery: restore the pre-merge pyproject.toml, then Retry as DB Connect setup (--no-constraints).

Why

E_PROVISION_CONFLICT is raised at the merge phase for a direct-pin disjoint (a version pinned in both the user's pyproject.toml and the cluster constraints). Conflicts that only uv's resolver finds — transitive dependencies, or clashes with databricks-connect's own dependency tree — instead fail during the sync as a generic E_PROVISION, and today get no recovery button. The Full tier's pinned cluster deps are the prime suspect for such a failure, so offering the DB-Connect retry (which drops those pins) closes the gap for the motivating "uv sync failed on conflicting versions" users.

How

• Recovery gate widened from E_PROVISION_CONFLICT to (E_PROVISION_CONFLICT || E_PROVISION) && !skipConstraints && backupPath.
• Reuses the existing recovery actions verbatim: [Retry as DB Connect setup] + [Open pyproject.toml], with Show Logs hidden (self-service) — identical to the provable-conflict path.
• Loop-safe: the gate requires the run carried the pins (!skipConstraints), so the --no-constraints retry can never re-enter recovery.
• Gating on the specific E_PROVISION code (not merely the provision phase) leaves E_PYTHON_INSTALL on its own "Select Python interpreter" remediation.
• Greenfield projects (no backupPath) fall through to today's handling.

Testing

• New unit tests: same recovery buttons on a generic E_PROVISION Full failure; the retry re-runs with --no-constraints and adopts the interpreter; no recovery on a pins-dropped (DB Connect) run; no recovery when there is no backup.
• yarn test:unit (1146 passing) and yarn test:lint both clean.

Notes

• Telemetry: the widened retry reuses the existing conflict_retry trigger; the preceding failure's errorCode (E_PROVISION vs E_PROVISION_CONFLICT) distinguishes a provable conflict from a suspected one in the funnel.

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: 2193
• Commit SHA: ca3a1d42e247e9dadedbb4a6fc9d99426e006b34

Checks will be approved automatically on success.

[rugpanov]

🤖 Integration tests ❌ failed for ca3a1d42.
View run

[rugpanov]

Closing in favor of a CLI-side fix.

Review of this extension-side widening showed that gating the "Retry as DB Connect" recovery on the generic E_PROVISION code is too coarse. E_PROVISION also covers failures where dropping the cluster pins cannot help: a blocked/unreachable package index (corporate proxy), disk/permission/uv errors, conflicts among the user's own dependencies, and conflicts rooted in databricks-connect's own dependency tree. In the index-unreachable case it would even hide the "Show Logs" button while the message points the user to the logs.

The recovery only resolves failures actually caused by the cluster pins — which is exactly what E_PROVISION_CONFLICT already certifies. The right layer for this is the CLI, which can see uv's resolver output and classify the cause. We'll widen the CLI's E_PROVISION_CONFLICT classification to also cover sync-time conflicts caused by the cluster pins; the extension's existing recovery (already gated on E_PROVISION_CONFLICT) then covers the new cases with no extension change.

Closing this PR; the work moves CLI-side.