fix: scope MCP project memory to workspace root

[caipira113]

Summary

• Inject ${workspaceFolder} into the MCP server as SUPERMEMORY_WORKSPACE_ROOT.
• Use the injected workspace root when resolving project config paths and project container tags.
• Keep process.cwd() as a fallback for non-Cursor or unresolved variable cases.

Why

Cursor can spawn plugin/global MCP servers with process.cwd() set to the user's home directory instead of the active workspace. When the MCP server uses process.cwd() to derive the project container tag, different projects can write to the same project container.

I observed this with two separate git projects, tessella and vibefolio, where MCP-saved project memories were both stored in the same container:

• cursor_project_76b5f714a5f645a1

That tag is derived from /home/iris, not from either project's git root.

A temporary debug MCP server confirmed that:

• process.cwd() was /home/iris for multiple workspace windows.
• ${workspaceFolder} resolved correctly per window:
  • /home/iris/Workspace/tessella
  • /home/iris/Workspace/vibefolio

Using ${workspaceFolder} keeps MCP project memory scoped to the actual workspace, matching the session hooks' existing behavior of using workspace_roots[0].

Reference: https://cursor.com/docs/mcp#config-interpolation

Test plan

• python3 -m json.tool .mcp.json
• python3 -m json.tool .cursor/mcp.json
• bun install --frozen-lockfile
• bun run typecheck
• bun run build
• Verified the built MCP server resolves distinct project tags when SUPERMEMORY_WORKSPACE_ROOT is set:
  • /home/iris/Workspace/tessella -> cursor_project_0c98f8e4016b9d7b
  • /home/iris/Workspace/vibefolio -> cursor_project_6bcaea3f70809028
• Verified the old fallback behavior remains when SUPERMEMORY_WORKSPACE_ROOT is not set:
  • cwd /home/iris -> cursor_project_76b5f714a5f645a1