fix(setup): reuse existing uv-created venv instead of failing on rerun

[Turkzilla]

Summary

uv venv refuses to write into an existing directory unless --clear is passed. The current setup_environment() in run-server.sh preserves uv-created venvs (by skipping the removal block when the uv_created marker exists), then unconditionally calls uv venv ... against that same directory.

That call fails on every run after the first with:

error: Failed to create virtual environment
  Caused by: A virtual environment already exists at `.pal_venv`. Use `--clear` to replace it

The script then logs uv environment creation failed and falls back to system Python detection, defeating the uv-first design and reinstalling all dependencies through pip on every run.

Fix

Add a fast-path that detects an existing healthy uv-created venv and reuses it (echoing the venv's python, matching the function contract).

If the uv_created marker is present but the Python interpreter is missing or non-executable, the venv is removed and recreated cleanly.

No behavior change for first-time setup or for non-uv venvs.

Test plan

• Existing healthy uv-created venv → fast-path reuses it, no uv venv call
• No venv → original code path runs uv venv --python 3.12
• Marker present but .pal_venv/bin/python missing → venv recreated cleanly
• Non-uv venv (no marker) → existing removal logic preserved
• bash -n run-server.sh syntax check passes

Repro of the bug (before this fix)

$ ./run-server.sh   # first run: succeeds, creates .pal_venv with marker
$ ./run-server.sh   # second run: fails with "already exists", falls back to system Python
Setting up environment with uv...
! uv environment creation failed, falling back to system Python detection
! uv output: Using CPython 3.10.18
Creating virtual environment at: .pal_venv
error: Failed to create virtual environment
  Caused by: A virtual environment already exists at `.pal_venv`. Use `--clear` to replace it

[gemini-code-assist]

Code Review

This pull request updates run-server.sh to allow the reuse of existing uv-created virtual environments, which prevents unnecessary recreations and ensures the uv-first design is maintained. A review comment identifies a potential issue where the Python executable path should be double-quoted to safely handle paths containing spaces.

[gemini-code-assist]

The variable $existing_python should be double-quoted when used as a command to prevent word splitting and globbing. This is particularly important if the path to the virtual environment contains spaces, which is common on some operating systems (e.g., macOS or Windows).

Suggested change

	print_success "Reusing existing uv environment ($($existing_python --version 2>&1))"
	if ! $existing_python -m pip --version &>/dev/null 2>&1; then
	print_success "Reusing existing uv environment ($("$existing_python" --version 2>&1))"
	if ! "$existing_python" -m pip --version &>/dev/null 2>&1; then