Document uv adoption migration paths and stale Base venv cleanup

[codeforester]

Context

Base now supports uv-managed Python projects through the explicit python.manager: uv contract. The core docs explain the model, but they do not yet give a short, practical migration recipe for users moving between Base-managed project virtualenvs and uv-managed project virtualenvs.

This came up while validating BankBuddy: basectl check bankbuddy correctly reported that Base will ignore a stale historical Base-managed project venv once the project declares uv management, but the docs should make the expected cleanup path more reassuring.

Desired documentation

Add a small migration section to the uv/Python manifest docs that covers both common paths:

1. A project starts without uv and uses Base’s historical project venv under ~/.base.d/<project>/.venv, then later adopts uv.
2. An existing uv-based project with a repo-local .venv adopts Base.

Points to clarify

• python.manager: uv is the explicit opt-in for uv-managed Python behavior.
• For uv-managed projects, Base treats <project-root>/.venv as the project environment unless BASE_PROJECT_VENV_DIR is explicitly overridden.
• Base delegates setup to uv sync; it does not solve dependencies, own uv.lock, or install [project].dependencies directly.
• Base intentionally ignores, rather than automatically deletes, a stale ~/.base.d/<project>/.venv.
• After basectl check confirms the uv project .venv is healthy, users may manually remove the stale Base-managed project venv if they no longer need it.
• Existing uv projects adopting Base should add python.manager: uv and only use runner: uv for commands that should execute through uv run -- ....

Acceptance criteria

• Canonical docs include a concise uv migration/adoption section.
• The section includes both Base-to-uv and uv-to-Base migration paths.
• The stale Base venv warning is explained in user-facing terms.
• The docs continue to state that Base does not infer uv ownership from pyproject.toml or uv.lock alone.
• .ai-context is updated if needed so future implementation agents preserve this boundary.