fix: install.sh venv detection, Windows path support, and install dir

[infinitimeless]

Problem

Reported by a user running the install script inside Pinokio on Windows with a pre-existing venv.

Three bugs were present:

1. Install directory defaulted to $HOME — INSTALL_DIR="$HOME/lmstudio-mcp" caused the script to break out of the user's working directory and install in their Windows home folder instead of where Pinokio (or any other launcher) invoked the script from.

2. No detection of an already-active venv — The script unconditionally created a new venv even if $VIRTUAL_ENV was already set (i.e. the user was already inside one). This broke Pinokio environments and any other tool that pre-activates a venv before running the script.

3. Hardcoded bin/activate path breaks on Windows — On Windows (Git Bash / MSYS2), the activate script lives at Scripts/activate, not bin/activate. The generated start_lmstudio_mcp.sh had the same hardcoded path.

Fix

• INSTALL_DIR now defaults to $(pwd) — install happens where the script is run from.
• already_in_venv() checks $VIRTUAL_ENV and $CONDA_DEFAULT_ENV before creating anything.
• find_existing_venv() searches common venv directory names (venv, .venv, env, etc.) before creating a new one.
• get_activate_path() tries bin/activate, Scripts/activate, and scripts/activate in order — works on Linux, macOS, and Windows.
• Generated start_lmstudio_mcp.sh and dev_setup.sh now use the detected path rather than the hardcoded venv/bin/activate.
• Added a trap on ERR so failures print the line number instead of silently dying.

Testing

Verified the following scenarios are handled correctly:

• Fresh install on Linux/macOS (creates venv/bin/activate)
• Fresh install on Windows Git Bash (creates venv/Scripts/activate)
• Running inside an existing venv — skips creation entirely
• Running from a Pinokio-managed directory — installs in place, not $HOME
• Existing venv present in directory — reuses it without recreating