Fix HTTP session inefficiency by sharing MultiIndexRunner across sessions

[augment-app-staging]

Problem

Currently in src/clients/mcp-http-server.ts, every new HTTP client session creates a fresh MultiIndexRunner instance via createMCPServer(). This causes redundant store.list() + store.loadSearch() calls for every index on every session, which is wasteful especially for S3-backed stores.

Solution

Share a single MultiIndexRunner instance across all HTTP sessions while maintaining per-session MCP Server instances (required by MCP protocol).

Changes

Modified src/clients/mcp-server.ts:

• Added optional runner?: MultiIndexRunner parameter to the MCPServerConfig interface
• Updated createMCPServer() function to:
  • Accept the optional runner parameter
  • If runner is provided, use it instead of creating a new one
  • If runner is not provided, create a new one (backward compatible behavior)
  • Keep all existing functionality intact
• Added comment explaining that updateClientUserAgent() call in the oninitialized callback will update the shared runner for all sessions (last writer wins), and that this is intentional behavior

Modified src/clients/mcp-http-server.ts:

• In createMCPHttpServer() function, create a single shared MultiIndexRunner instance during server initialization (before the session handling logic)
• Pass this shared runner to each per-session createMCPServer() call
• Added comments explaining the shared runner approach

Testing

• ✅ All existing tests pass (193 passed)
• ✅ Build succeeds without errors
• ✅ Backward compatible: runner parameter is optional
• ✅ Stdio MCP server still works (unaffected by changes)
• ✅ HTTP MCP server now shares runner across sessions

Key Benefits

• Eliminates redundant store.list() + store.loadSearch() calls for every HTTP session
• Especially beneficial for S3-backed stores where these operations are expensive
• Maintains per-session MCP Server instances as required by MCP protocol
• Fully backward compatible

Notes

• The updateClientUserAgent() behavior in the oninitialized callback will affect all sessions when using a shared runner (last writer wins). This is acceptable and documented with a comment.
• The MultiIndexRunner already handles lazy client caching, so sharing it is safe.

Related: https://slack.com/archives/C0ACX5SLML7/p1770850068455299