Reject Unity bridge project mismatches

[Eli Pinkerton (wallstop)]

DISCLOSURE: LLM-GENERATED TEXT

Why: Bridge startup can silently reuse a different Unity project.

What:

• Reject mismatched or unknown project ownership before reuse.
• Preserve existing bridges and client settings when startup fails.
• Accept equivalent project paths and matching unpinned startup.
• Cover project mismatches and document recovery steps.

Fixes #301

---

Note

Medium Risk
Changes when the host bridge short-circuits startup versus fails, which affects local dev workflows but is guarded by tests and leaves an existing listener untouched on mismatch.

Overview
Unity MCP host bridge reuse is now gated on project ownership, so startup no longer treats a healthy listener on the preferred port as reusable when its pinned (or unpinned) project does not match the requested settings.

existing_bridge takes the requested projectPath, compares it to /healthz via new same_project (os.path.samefile for absolute paths; empty strings match only when both sides are unpinned). A mismatch raises ValueError with a clear message, exits startup with code 1, and does not alter the running bridge or .env.local. Equivalent spellings (trailing separators, .., symlinks, Windows case/slash variants) still count as the same project for the “already running” fast path.

Integration and unit tests cover pinned↔unpinned mismatches, unknown projectPath types, and alias acceptance. .llm/mcp/README.md documents the failure mode and recovery (different --port or stop the old bridge).

^{Reviewed by Cursor Bugbot for commit 30605b7. Bugbot is set up for automated code reviews on this repo. Configure here.}