codeanalyzer builds a per-project analysis virtualenv
(<cache>/.codeanalyzer/<project>/virtualenv) and installs the target project's
dependencies -- and the project itself, editable -- so Jedi can resolve
third-party imports for the call graph. Two defects make this both ineffective
and slow.

1. Missing wiring (correctness)

Codeanalyzer.__init__ sets self.virtualenv = None and never reassigns it to
the built venv. SymbolTableBuilder therefore receives virtualenv=None and
Jedi falls back to the default environment, so the installed dependencies are
never used and external / third-party call edges go unresolved. The expensive
install currently buys nothing.

The assignment must run on both a fresh build and a lazy reuse of an existing
venv (the build is guarded by if not venv_path.exists() or rebuild_analysis,
which is skipped on reuse).

2. Use uv instead of pip (performance)

Dependency installation must use uv (uv pip install --python <venv>)
rather than python -m pip install. uv resolves and downloads in parallel
against a shared global cache, which is dramatically faster for large dependency
trees (e.g. Odoo). uv ships as a self-contained binary in its PyPI wheel, so it
is present wherever canpy is installed -- including Docker images; fall back to
pip only when uv cannot be located.

Acceptance

• self.virtualenv points at the analysis venv whenever it exists, and Jedi
  resolves the project's installed dependencies.
• dependency installation uses uv when available and pip otherwise.