Emit E_PROVISION_CONFLICT for uv sync resolution conflicts

[rugpanov]

Why

databricks environments setup-local wrapped every provisioning failure as
E_PROVISION. The VPEX extension's recovery flow needs to distinguish a
dependency version conflict — the project's dependencies can't be satisfied
against the pins this command wrote for the target environment — from a generic
failure it can't fix by relaxing constraints (a build-backend error, a permissions
problem, a transport error). Fixes DECO-28365.

What

• New error code E_PROVISION_CONFLICT (libs/localenv/result.go), reported
  from the provision phase.
• The merge phase already detects a provable version conflict between the
  user's dependencies and the environment pins and records it as the
  W_USER_CONSTRAINT_CONFLICT warning (libs/localenv/warnings.go, PEP 440
  interval math on provably-disjoint ranges, scanning every requirement uv locks).
• When that warning is present, uv sync would deterministically fail to resolve,
  so the pipeline fails fast: right after the merge writes the project files it
  reports E_PROVISION_CONFLICT (failurePhase=provision, diskMutated=true)
  without attempting the Python install or uv sync
  (libs/localenv/pipeline.go, hasConstraintConflictWarning). Every other
  provisioning failure keeps E_PROVISION.
• Gating on the CLI's own merge detection (rather than parsing uv's stderr) keeps
  the code precise — no false positive on an unavailable package or an
  unrelated sync failure — and needs no brittle stderr matching. diskMutated=true
  is preserved because the constraints are written before the check, which the
  extension's recovery flow relies on.
• --dry-run is unchanged: it computes a plan and does not evaluate provisioning,
  so the same conflict surfaces there as the W_USER_CONSTRAINT_CONFLICT warning
  (ok=true) — a test pins that intended divergence.
• Telemetry: adds SetupLocalErrorCodeProvisionConflict and the mapping case
  (cmd/environments/telemetry.go, libs/telemetry/protos/setup_local.go), kept
  exhaustive by the linter and TestErrorCodeCoversLocalenv.

Consumer-facing note

Adding E_PROVISION_CONFLICT is additive, but this exact scenario previously
surfaced as E_PROVISION. Any consumer that special-cased E_PROVISION for the
conflict case will see the new code. The universe lumberjack proto should add the
matching SetupLocalErrorCode enum value (ingestion ignores unknown values, so the
two changes can land in either order).

Testing

• Unit (libs/localenv/pipeline_test.go): a conflict warning makes the run
  report E_PROVISION_CONFLICT at the provision phase with diskMutated=true and
  without invoking Python install or sync (recordingPM records neither);
  --dry-run with the same pins reports ok=true with the warning and no error,
  writing nothing. TestPipelineRetainsFallbackResolutionWhenProvisioningFails
  still covers a generic sync failure → E_PROVISION.
• Acceptance (acceptance/localenv/provision-conflict/): a real setup-local
  run where the user pins pip==24.0 and the remote constraints pin pip<24; the
  merge flags the conflict and the command reports E_PROVISION_CONFLICT before
  provisioning. Cross-platform (only preflight uv --version runs; the doomed sync
  never does), so it runs on every OS with no fake binary.
• gofmt, go vet, golangci-lint, and the local check-changelog pass.

This pull request and its description were written by Isaac.

[rclarey]

If we already know the pins are unsatisfiable why do we wait for uv sync to fail? Why not error right away?

[rugpanov]

Good call — now we error right away.

[eng-dev-ecosystem-bot]

Integration test report

Commit: 6c07a2b

Run: 33888334586

	Env	💚​RECOVERED	✅​pass	🙈​skip	Time
💚​	aws linux	1	275	16	6:15
💚​	aws windows	1	277	14	4:08
💚​	azure linux	1	274	16	7:07
💚​	azure windows	1	276	14	4:12
💚​	gcp linux	1	275	16	7:05
💚​	gcp windows	1	277	14	4:29

	Test Name	aws linux	aws windows	azure linux	azure windows	gcp linux	gcp windows
💚​	TestAccept	💚​R	💚​R	💚​R	💚​R	💚​R	💚​R

Top 6 slowest tests (at least 2 minutes):

duration	env	testname
4:20	gcp windows	TestAccept
4:05	aws windows	TestAccept
4:04	azure windows	TestAccept
4:02	azure linux	TestAccept
3:48	aws linux	TestAccept
3:39	gcp linux	TestAccept