[skills] Record downloaded-skill attribution in ~/.ucode/skills.json

[xsh310]

What

Track which on-disk skill directories ucode downloaded from Unity Catalog, in a
single manifest at ~/.ucode/skills.json, so ucode can tell a downloaded skill
from a user-authored one and (in a later PR) remove downloads by their UC schema.

Skill attribution design doc:
https://doc-center-6051921418418893.staging.aws.databricksapps.com/d/hbzhsbid

Why

The download path kept no record of what it wrote or where it came from, so there
is no safe way to remove a downloaded skill without risking a same-named skill the
user authored themselves. This is the foundation (PR 1 of the attribution work): it
populates the manifest but adds no user-facing command yet.

Changes

• New skills_state.py owns the manifest and its read/write/query/reconcile logic.
  Records are keyed by (metastore_id, fqn, base); query helpers are
  list_downloaded, attribution_for_dir, records_for_schema, and forget.
• record_downloads reconciles superseded records on write: it drops the stale
  record for a directory just overwritten (keeping the freshly written files) and
  deletes the orphaned old directory when the same skill's bundle name changed.
• SkillRef now also carries metastore_id, skill_id, and uc_update_time,
  read for free from the ListSkills/GetSkill response ucode already fetches.
• The three download flows (whole-schema, named FQNs, picker) and the managed-launch
  download record each skill after it reaches disk.

Kept separate from state.json so a state-version change and ug revert leave it
untouched.

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). New tests/test_skills_state.py covers the manifest
round-trip, corrupt/version handling, the queries, and all three reconciliation
cases; tests/test_skills_download.py gains coverage that a download records
attribution and that SkillRef captures the UC metadata.

Stack

Part of gh stack #576, on top of #583 (skills-picker-skills-fqn).

This pull request and its description were written by Isaac.

[sunishsheth2009]

P2: the manifest is a read-modify-write (_load → mutate → _save) with no locking. Two concurrent ucode invocations (e.g. a download in one shell, a remove in another) can interleave so the second clobbers the first's update — a just-recorded skill silently vanishes from attribution. atomic_write_json keeps the file well-formed but doesn't prevent the lost update. Rare in practice; worth a file lock or a re-read-before-write if concurrent runs are plausible.