refactor: consolidate nvim crates, extract server library, and update workspace dependencies

agent-rules/nvim_architecture.md

@@ -1,16 +1,15 @@
-# Neovim MCP Architecture (Dual-OS)
+# Neovim MCP Architecture (Cross-Platform)
 
-We use a modular, multi-binary approach for MCP Neovim integration to cleanly separate Windows and Linux concerns, avoiding complex cross-OS `wsl.exe` bridging within the main `mcp-memory-server`.
+We use a modular, cross-platform approach for MCP Neovim integration to cleanly connect with Neovim instances across Windows and WSL.
 
 ## The Architecture
 1. **`mcp-memory-server`:** The core Windows daemon (handles state, lock-files, and global graph).
 2. **`mcp-memory-stub`:** The WSL proxy that forwards standard json-rpc to the Windows daemon.
-3. **`mcp-memory-win-nvim`:** A dedicated Windows-native MCP server. Its sole responsibility is finding active Neovim instances running natively on Windows and sending RPC commands to them.
-4. **`mcp-memory-linux-nvim`:** A dedicated Linux-native MCP server running inside WSL. Its sole responsibility is finding active Neovim instances inside WSL (including Tmux sessions) and sending RPC commands to them.
+3. **`mcp-memory-nvim`:** The unified cross-platform Neovim MCP server binary (`mcp-memory-nvim.exe` on Windows, `mcp-memory-nvim` on Linux). Its sole responsibility is finding active Neovim instances (via named pipes on Windows or domain sockets on Unix/WSL) and sending RPC commands to them.
 
-This isolates editor-control logic to the native OS where the editor is actually running.
+This isolates editor-control logic natively to whichever OS environment execution is running in.
 
-## How the Respective MCP Servers Get Called
+## How the MCP Server Gets Called
 
 The Antigravity CLI (`agy`) acts as the MCP Client and automatically manages the lifecycle of these servers. 
 
@@ -19,18 +18,18 @@ The Antigravity CLI (`agy`) acts as the MCP Client and automatically manages the
    - Windows: `C:\Users\reazul.ashraf\.gemini\config\mcp_config.json`
 
 2. **Execution:** 
-   When `agy` starts up, it reads `mcp_config.json`. If it finds `"linux-nvim": { "command": "/home/riz/.local/bin/mcp-memory-linux-nvim" }`, it will spawn that binary as a background subprocess using standard `stdio`.
+   When `agy` starts up, it reads `mcp_config.json`. If it finds `"win-nvim": { "command": "C:\\Users\\reazul.ashraf\\.local\\bin\\mcp-memory-nvim.exe" }`, it will spawn that binary as a background subprocess using standard `stdio`.
 
 3. **Communication:**
    - The LLM requests to use a tool (e.g., `nvim_goto_line`).
-   - The `agy` CLI sends a JSON-RPC request to the `mcp-memory-linux-nvim` subprocess via its `stdin`.
-   - The Rust MCP Server receives the request, connects to the Neovim active socket (`~/.gemini/active_nvim.txt`), sends the Msgpack-RPC command, and writes the JSON-RPC response back to `stdout`.
+   - The `agy` CLI sends a JSON-RPC request to the `mcp-memory-nvim` subprocess via its `stdin`.
+   - The Rust MCP Server receives the request, connects to the Neovim active socket/pipe (`~/.gemini/active_nvim.txt` or `\\.\pipe\nvim.*`), sends the Msgpack-RPC command, and writes the JSON-RPC response back to `stdout`.
    - The `agy` CLI reads the response from `stdout` and returns it to the LLM context.
 
 ## Capabilities & Requirements
 To use this architecture, Neovim must run the `gemini-integration.lua` script to broadcast its active socket to `~/.gemini/active_nvim.txt`.
 
-The MCP servers provide 5 core tools:
+The MCP server provides core tools including:
 1. **`nvim_goto_line`**
 2. **`nvim_set_diagnostics`**
 3. **`nvim_get_active_buffer`**

agent-rules/nvim_editing.md

@@ -8,10 +8,10 @@ trigger: always_on
 ## Never Spawn Headless Instances (CRITICAL)
 **NEVER** run `nvim <filename>` via bash/terminal commands (`run_command`) to "open" or "show" a file to the user. Because agent terminal commands run in the background, this spawns an invisible ghost process. 
 
-If the user asks to "open", "show", or "see" a file in Neovim, you MUST use the `linux-nvim` (or `win-nvim`) MCP Server to communicate with their *active* UI (e.g., using `nvim_execute_lua` with `vim.cmd('edit <file>')`).
+If the user asks to "open", "show", or "see" a file in Neovim, you MUST use the `win-nvim` (Neovim) MCP Server to communicate with their *active* UI (e.g., using `nvim_execute_lua` with `vim.cmd('edit <file>')`).
 
 When making code edits or displaying search results/outputs:
-1. Verify if the win-nvim (on Windows) or linux-nvim (on WSL) MCP server is responsive.
+1. Verify if the `win-nvim` (Neovim) MCP server is responsive.
 2. If Neovim is running, apply code changes directly into the relevant Neovim buffers using nvim_execute_lua (e.g., using vim.api.nvim_buf_set_lines or vim.cmd).
 3. DO NOT output large diffs or file contents to the chat console. Prefer live buffer manipulation over replace_file_content if the file is open in Neovim.
 4. **Fallback Constraint (CRITICAL):** If Neovim is NOT running, you MUST use the `replace_file_content` tool to edit files. This ensures the user is presented with a visual diff block in the chat. **NEVER** use `sed`, `awk`, or `echo` to blindly modify file contents from the terminal.

agent-rules/nvim_mcp_enforcement.md

@@ -1,6 +1,6 @@
 # Neovim MCP Enforcement Rule
 
-When interacting with the user's Neovim editor (e.g., opening a file, moving the cursor, reading the active buffer, setting diagnostics), you MUST ALWAYS use the MCP tools provided by the `linux-nvim` (WSL/Linux) or `win-nvim` (Windows) MCP servers. 
+When interacting with the user's Neovim editor (e.g., opening a file, moving the cursor, reading the active buffer, setting diagnostics), you MUST ALWAYS use the MCP tools provided by the `win-nvim` (Neovim) MCP server. 
 
 - You are strictly forbidden from using bash scripts, `nvim --server`, or other raw terminal/shell hacks to remote-control Neovim.
 - You must rely entirely on the MCP tool registry (e.g., `nvim_goto_line`, `nvim_get_active_buffer`, `nvim_get_cursor`, `nvim_get_visual_selection`, `nvim_set_diagnostics`).