1.4.2

Two MCP sessions can now drive one server. Both failures below showed up the same way — one session worked and the other appeared not to connect — and neither said why.

Fixed

wait_for starved every other client. The agent served requests from four threads, and wait_for sits on its thread for up to a minute while a condition comes true. Four concurrent waits therefore held every thread the agent had, and each further request — from any session — queued until one finished. A second session's call never returned and its MCP client timed out.

Measured against a real agent, four waits in flight:

	idle	four waits running
before	0.08s	28.01s
after	0.08s	0.00s

Waits now run on a pool of their own, bounded at 32. Past that a caller gets 429 and a message saying so, rather than joining a queue and later reporting a timeout it never spent waiting.

A bot name already on the server evicted whoever held it. A bot's UUID is derived from its name — that is what makes Tester1 the same player every run — so two sessions using one name are one player, and the server admits a player once. It resolves the clash by taking the newcomer and kicking the incumbent.

Which side lost was a race. Often the second bot_spawn was rejected; sometimes it won and the first session's bot vanished with nothing reported, its own bot_spawn having already returned success.

bot_spawn now asks whether that player is online before connecting and refuses if so, leaving the existing bot alone. A rejection that still races through explains itself instead of arriving as the bare translation key multiplayer.disconnect.duplicate_login.

Upgrading

Give each session its own bot names. Lobby_Tester1 and Survival_Tester1 rather than Tester1 twice. Names are identities here, so sharing one across sessions was never going to mean two players — the difference is that it now says so instead of quietly dropping one.

Nothing else changes. session_start was never the problem: two of them against one agent both return in 0.53s, before and after.