bug: Race condition in mcp-server/server.py _init() under concurrent requests

Context

mcp-server/server.py uses lazy initialization in _init() (lines 18–23) to set up the MilvusClient and encoder. There's no lock around this.

Problem

Under concurrent WebSocket connections at startup, multiple callers can enter _init() before the first one completes — so the client and encoder get initialized multiple times, or a second request reads partially-initialized state.

• PR #66 adds an encoder singleton but leaves this race unaddressed.

Why This Order

Needs to land after #28 (MilvusClient standardization) since both touch the same init path. Must be fixed before the Kagent-managed agent layer builds on top of these servers.

Acceptance Criteria

• _init() is safe under concurrent calls — second caller blocks until first completes, then reuses the result
• No double-initialization in logs under load
• Verified with a concurrent connection test

Related

• mcp-server/server.py:18-23
• PR #66 — partial fix (encoder singleton only)
• Parent tracking issue: #72
• Depends on: #28 (ISSUE-01)
• Blocks: Kagent agent layer (multi-index MCP tools)

Start with mcp-server/server.py lines 18–23 and read the lazy initialization path for MilvusClient and the encoder. Review PR #66 and the dependency on #28 before adding a concurrent connection test. Done means concurrent calls block safely, reuse one initialization, and produce no double-initialization logs under load.