Make the CLI version update a no-op; download skills from the Skills/ root

[xsh310]

Two independent changes to how ucode talks to Databricks.

---

1. Make the Databricks CLI version update a no-op

Why

install_databricks_cli() used to read databricks --version and, whenever it was below MIN_DATABRICKS_CLI_VERSION (1.0.0), shell out to replace the install: brew upgrade databricks/tap/databricks on macOS, or curl | sudo sh / wget | sudo sh on Linux, or irm ... | iex on Windows.

That silently swaps out a CLI the user manages themselves, including a locally built one, and does it with sudo on Linux. Failing a feature with the CLI's own error message is less disruptive than mutating the developer's toolchain out from under them.

What changed

• ensure_databricks_cli_version() is now a no-op. It is kept as a seam so callers do not need to know whether a version policy exists.
• install_databricks_cli() is renamed ensure_databricks_cli(). It only checks PATH and raises with install instructions when databricks is missing; it never installs.
• Removed _run_databricks_cli_installer(), _parse_databricks_cli_version(), MIN_DATABRICKS_CLI_VERSION, and the two setup-cli install URLs.
• Reworded the stale comment in install_ai_tools() that claimed the CLI version was already guaranteed.
• README lists the Databricks CLI as a prerequisite, with a link to the install guide and a note to keep it current.

Behavior change

A user with no databricks on PATH previously got an automatic install; they now get an actionable error pointing at the install docs:

ERROR Databricks CLI was not found on PATH. Install it, then re-run this
command: see https://docs.databricks.com/aws/en/dev-tools/cli/install (on macOS:
`brew install databricks/tap/databricks`).

A user on an old CLI previously got an automatic upgrade; they now proceed and, if they hit a subcommand their CLI lacks (for example databricks aitools), see the CLI's own error. install_ai_tools() only warns on failure, so that path degrades rather than breaks.

---

2. Download skill bundles from the Files API Skills/ root

Why

configure skills fetched bundle content from Volumes/{catalog}/{schema}/{leaf}/..., but skill bundles are served under the Files API's Skills/ root. The Volumes/ path does not hold the bundle.

What changed

• fetch_skill_file() now requests https://{hostname}/api/2.0/fs/files/Skills/{catalog}/{schema}/{leaf}/{relative_path}.
• list_skill_files() walks GET /api/2.0/fs/directories/Skills/... and strips the matching /Skills/... prefix.

Both halves have to move together: relative paths are produced by stripping the prefix off the absolute paths the listing returns, so a half-applied change yields unstripped paths rather than a clean failure. Added SKILL_FILES_ROOT so the root is stated once.

Testing

uv run ruff check . passes. Full non-e2e suite passes: 1216 tests.

• TestEnsureDatabricksCliVersion rewritten to pin the no-op contract: never raises for a new, old, or unparseable version, and shells out to nothing.
• New TestEnsureDatabricksCli covers the PATH hit, the actionable raise on a miss, and that no install is ever attempted.
• The version-parser and installer test classes are dropped along with the code they covered.
• New test_walks_the_skills_root_not_volumes pins the directory-listing URL. Previously only the file-fetch URL was asserted, so a half-applied prefix change would have gone unnoticed.

Also smoke-tested the built tool from this branch (uv tool install --reinstall "git+https://github.com/xsh310/ucode@noop-cli-version-update") and confirmed the missing-CLI error above appears with databricks off PATH.

E2E tests were not run: they need a live workspace. The Skills/ download path in particular is covered only by unit tests here, so it is worth exercising ucode configure skills --location <cat>.<sch> against a real workspace before merge.

This pull request and its description were written by Isaac.