fix: support uv-managed Python in dev mode project creation on macOS

[AMagicPear]

Problem

On macOS with uv-managed Python (and other non-conda Python installations), creating a new project in dev mode fails with SIGABRT:

Error: Command '[.../.venv/bin/python3.12', '-m', 'ensurepip', '--upgrade', '--default-pip']' died with <Signals.SIGABRT: 6>

Even when ensurepip doesn't abort, a subsequent 'Library not loaded' error appears because venv --copies copies the python executable but not libpython3.12.dylib:

dyld: Library not loaded: @executable_path/../lib/libpython3.12.dylib
  Referenced from: [.../.venv/bin/python]
  Reason: tried: '[...perrytest/.venv/lib/libpython3.12.dylib' (no such file)

Root Cause

On macOS, Python binaries are linked with @executable_path/../lib/libpython3.12.dylib. When venv --copies is used:

1. The python executable is copied to the target venv
2. libpython3.12.dylib is NOT copied — it still lives at the original Python's lib/ path
3. The copied executable's @executable_path resolves to the target .venv/, where the dylib doesn't exist
4. ensurepip (called internally by venv) also fails because it writes to hardcoded paths in the original venv

Fix

1. project_model.py: Remove --copies from venv call (use symlink mode, the default). After venv creation, manually bootstrap pip using the host Python's pip with pip install --target to avoid ensurepip entirely.

2. stage_bundled_python_runtime.py: Add a fallback in _ensure_pip() — if ensurepip fails, copy pip from the host Python's site-packages instead of aborting.

Testing

• Create new project on macOS with uv-managed Python 3.12
• Engine launches and enters project successfully
• Existing conda workflow (not tested yet)