Add single-instance guard for MCP stdio server

[Hohlas]

Hi @lyonzin,

This PR adds a single-instance guard for the knowledge-rag MCP server.

Problem

Some MCP stdio clients can start multiple knowledge-rag processes even during a single visible user session/request. In my case this happened from one chat: the client opened additional internal MCP connections during approval/review flow, so several independent knowledge-rag processes were spawned although I was not intentionally running parallel chats.

Each process loads its own embedding model, ChromaDB client, BM25 state, and file watcher. On larger local indexes this can quickly consume several GB of RAM and may exhaust system memory.

Fix

The server now creates data/knowledge-rag.lock on startup and refuses to start a second instance while the first one is still alive.

The guard:

• writes the current PID to the lock file;
• checks whether an existing PID is still running;
• exits with code 75 if another server is active;
• removes stale lock files when the previous process is gone;
• cleans up the lock on normal termination and SIGINT/SIGTERM.

The lock is applied in server.main(), so it protects all entry points that run the MCP server, including direct knowledge-rag, python -m mcp_server.server, and wrapper-based launches.

Validation

I reproduced the issue by starting multiple MCP stdio server instances with open stdin. Each instance stayed alive independently and loaded its own model/watcher.

After this patch, the second server exits immediately with:

knowledge-rag MCP server is already running

Added tests cover:

• rejecting a second running instance;
• recovering from a stale lock file.