Local MCP tool calls approved but never forwarded to server

### What happened?

## Summary
A local MCP server (filesystem-type, pointed at an Obsidian vault) worked earlier today, then started failing every tool call with a generic "Tool execution failed" on the client side. The server process itself is healthy — logs show it never actually receives the call.

### Environment
- Claude Desktop, macOS
- Local server launched via `npx` (resolved through an `fnm`-managed Node path)
- Server: filesystem-type MCP (`obsidian-brain-filesystem`), pointed at a local directory
### Steps to reproduce
1. Have a working local filesystem-type MCP server connected
2. At some point during the day, tool calls to it start returning "Tool execution failed" with no further detail
3. Tail `~/Library/Logs/Claude/mcp.log` and `~/Library/Logs/Claude/mcp-server-.log` while triggering a tool call
### Observed behavior
- `mcp-server-.log` shows a clean handshake: `Initializing server...` → `Server started and connected successfully` → `initialize` → `notifications/initialized` → `tools/list` all complete with results
- `mcp.log` (the router-level log) shows the identical clean handshake for the server
- After that point, **no `tools/call` entry ever appears in either log**, regardless of how many times a tool is invoked from the client
- Client-side, every call returns "Tool execution failed" immediately
### What I tried (none resolved it)
1. Restarted the individual MCP server process (clean shutdown + reinit observed in logs) — no change
2. Started a brand-new chat conversation — no change
3. Fully quit (`Cmd+Q`) and reopened Claude Desktop, confirmed via `mcp.log` that *all* servers cleanly reinitialized — no change
4. Closed all other Claude Desktop windows/tabs, left only the one conversation focused, to rule out a session being bound elsewhere — no change
### Possible lead
`~/Library/Application Support/Claude/bridge-state.json` appears to track only a single `localSessionId` ↔ `remoteSessionId` pairing at a time:

```json
{
"f6a55994-2686-4d67-ad9d-fdee9650adbc:10018aa7-3831-4238-a74b-fd8196335b9e": {
"enabled": true,
"userConsented": true,
"environmentId": ,
"localSessionId": ,
"remoteSessionId": ,
"processedMessageUuids": [],
"pendingProcessedAcks": []
}
}
```

If this file is meant to route approved tool calls to the correct local session, a stale or mismatched pairing here seems like a plausible cause for calls silently not being forwarded — though this is a guess, not confirmed.

### Impact
Local filesystem-type MCP servers become completely unusable for the rest of the session/day with no client-side error detail to self-diagnose, and no recovery path short of Anthropic-side investigation.

### What did you expect to happen?

Successful MCP tool call

### Steps to reproduce

1. Have a working local filesystem-type MCP server connected
2. At some point during the day, tool calls to it start returning "Tool execution failed" with no further detail
3. Tail `~/Library/Logs/Claude/mcp.log` and `~/Library/Logs/Claude/mcp-server-.log` while triggering a tool call

### Area

Tool Discovery / Invocation

### MCP Server (if applicable)

_No response_

### Error messages or logs

```shell

```

### Additional context

_No response_