[skills] Support removing downloaded skills

[xsh310]

What

Wire the download side of ug skill remove (until now it errored with "not
supported yet"), mirroring ug skill add's surface. Builds on #584, which records
what was downloaded from Unity Catalog.

Why

With the attribution manifest in place, ucode can finally delete downloaded skills
safely: removal is driven entirely by attribution, so a same-named skill the user
authored themselves is never touched. That safety is the reason this could not ship
before the manifest.

Behavior

• ug skill remove --location <catalog.schema> deletes every skill downloaded from
  that schema, across all download bases; --path limits it to one base.
• ug skill remove --skills <fqn>[,<fqn>...] deletes named fully-qualified skills
  that may span schemas (parity with ug skill add --skills).
• ug skill remove with none of those opens a picker over every downloaded skill,
  across all bases, each row labeled <fqn> (<scope>: <base>).
• --mcp removal is unchanged; --agents remains --mcp-only, and --location /
  --path / --skills are rejected with --mcp.

Changes

• skills_state.remove_downloads deletes each record's directories, then forgets it;
  records_for_fqns looks records up by fully-qualified name.
• remove_downloaded_skills_command and the removal picker live in skills_download,
  next to the download flows they mirror.
• ug skill remove grows --location, --path, and --skills.

Testing

uv run ruff check, ruff format --check, ty check src, and uv run pytest all
pass (the pre-existing test_e2e_user_agent / test_claude_smart_routing_v2
failures also fail on the base). Added unit coverage for remove_downloads and
records_for_fqns, the by-location / by-name / picker removal paths (including that
a user-authored directory is left alone), and the CLI routing and argument validation.

Screen.Recording.2026-09-12.at.12.17.52.PM.mov

Stack

Part of gh stack #576, on top of #584 (skills-download-attribution).

This pull request and its description were written by Isaac.

[sunishsheth2009]

P2: remove_downloads deletes the on-disk dirs first, then forget() rewrites the manifest. If _save fails after deletion (disk full, etc.), the files are gone but their records remain → phantom entries pointing at deleted dirs on the next run. Also, _delete_dirs uses shutil.rmtree(..., ignore_errors=True), so a dir that's a symlink is silently skipped yet still forget()-ten — the link lingers with no signal. Both are minor; consider forgetting-then-deleting, or at least noting undeletable paths.