Add ucode apply: publish the authored managed config

[tt-le]

Changes

Stacked on #270 — review that first. This PR's diff includes the rest of the stack until those merge.

The publish step for the manifest ucode setup authors. Validates, shows what would change, confirms, then writes it to the workspace using the clients from #270. This completes the admin path: author (ucode setup) → review (ucode setup show) → publish (ucode apply).

ucode apply             # validate, preview, confirm, publish
ucode apply --dry-run   # validate and preview without writing
ucode apply --yes       # skip the confirmation (CI)

It updates in place rather than replacing

When the workspace already has a config, apply PATCHes it using its resource name, read back from the existing-config GET (normalize_managed_config preserves name).

Delete-then-create was the original plan, since v0's Create returns ALREADY_EXISTS. But that has a window where the workspace has no managed config — and if the create failed there, every developer would silently fall back to their own settings until someone re-ran the command. The server applies the update mask inside a single entity-store update, so a failed PATCH leaves the current config intact.

It is still a whole-manifest write: every path ucode owns is sent, so a field the admin dropped on a re-run is cleared rather than left behind.

It refuses to publish when it can't tell whether a config exists

A failed existence check is the one case where "just try the create" either duplicates or silently overwrites an admin's work. So an unreadable check is a hard error naming the reason, not a warning that proceeds.

Error mapping

_explain_publish_failure covers the failures an admin will actually hit:

Server error	What ucode says
FEATURE_DISABLED	Names codingAgentConfigCrudEnabled and who to ask — this is the likely first experience, since the CRUD flag is off by default
PERMISSION_DENIED	Workspace admin is required to author the workspace's coding config
INVALID_PARAMETER_VALUE	Passed through verbatim — the server names the offending field, which beats any paraphrase
ALREADY_EXISTS	Shouldn't happen once we PATCH; suggests re-running

The admin gate and validation both run before anything is sent, so an invalid manifest or a non-admin costs no round trip.

Testing

uv run pytest — 1372 passed, 6 skipped. 19 new cases.

Mutation-verified three ways: always-create instead of PATCH, publishing despite an unreadable existence check, and publishing an invalid manifest each fail a specific test. Also covers that typer.Exit(0) isn't swallowed by the command's own RuntimeError handler — the same trap setup hit, where a successful run printed ERROR 0.

Verified against a staging workspace:

╭─────────────╮
│ ucode apply │
╰─────────────╯
✔ Databricks auth already available
✔ Admin permissions verified

Configuration summary
  Default agent: Claude Code
  Claude Code: system.ai.claude-sonnet-5 (per-user)
    opus: system.ai.claude-opus-5
    sonnet: system.ai.claude-sonnet-5
  Budget policy: my_policy_name
    at 50%: Claude Code / system.ai.claude-sonnet-5
    at 90%: Codex / system.ai.gpt-5-6-sol

! This will replace the config already published on <workspace>
  (currently: claude). Every developer picks the new one up on their
  next ucode run.
✔ Dry run: the config was validated but not published.

That exercised auth, the admin check, the summary, and the existing-config detection choosing the update path — without writing.

README

Documents the publish step and drops the "no partial update yet" caveat, which the PATCH path makes untrue.

Not included

A pre-publish validation probe (launching each agent to confirm its model actually answers) is deliberately out of scope — it needs its own retry UX and would roughly double this PR. Better as a follow-up or a --probe flag.

This pull request and its description were written by Isaac.