feat: implement real pixi launch path for conda environments

[rgbkrk]

When a pixi.toml is detected, the daemon labels the source as conda:pixi and shows a pixi icon, but the kernel actually runs in a generic prewarmed conda env that has nothing to do with the project's dependencies. The pixi.toml's deps, lockfile, and environment are completely ignored at runtime.

Additionally, convert_to_conda_dependencies() silently drops [pypi-dependencies] when importing — only conda deps make it through. This defeats pixi's main value proposition of handling both conda and pip deps in a single lockfile-resolved environment.

Current state

• Detection: ✅ find_pixi_toml() walk-up works, PixiInfo struct parses deps/channels/pypi-deps
• Kernel launch: ❌ conda:pixi falls through to wildcard match, grabs a generic pooled env
• PyPI deps: ❌ Dropped on import (convert_to_conda_dependencies only converts conda deps)
• Pixi CLI: ❌ Never invoked — no pixi run, no pixi install, no bootstrapping

Proposed approach

1. pixi run launch path — when conda:pixi is detected, launch via pixi run python -m ipykernel_launcher -f <conn_file> in the project directory. Skip the pool. This uses pixi's lockfile-resolved env with both conda and pip deps.
2. Pixi CLI bootstrapping — add get_pixi_path() to kernel_launch::tools (bootstrap via rattler from conda-forge, same pattern as deno/uv)
3. Handle [tool.pixi] in pyproject.toml — currently pyproject.toml always maps to uv:pyproject, but pixi can be configured there too. Need detection for this case.
4. Fix PyPI dep handling in import — when importing pixi deps to notebook metadata, include pip deps

h/t @rahuldave

[rgbkrk]

Additional context from Kyle: we're already using rattler for conda env creation, so the approach here might not need the pixi CLI at all. If rattler can resolve pixi.toml lockfiles (including pip packages), we could do this entirely through rattler — same pattern as the existing conda env creation in kernel-env/src/conda.rs, just reading from pixi.toml instead of inline deps.

That would also avoid the bootstrapping step and keep the dependency surface smaller. The key question is whether rattler's solver can handle pixi's [pypi-dependencies] natively or if that needs separate uv pip install handling after the conda solve.