feat(worker-mcp): raise wait_for_task_change timeout, expose queue slot state

MaxTimeoutSeconds was 170s against runs that take tens of minutes, forcing
a dozen full-context wait rounds per long-running batch. Raise it to 900s
and raise MCP_TOOL_TIMEOUT in lockstep (ClaudeProcess + every
InteractiveLaunchSpecService launch spec) to 930000ms so the client
connection actually stays open that long instead of aborting first.

Add get_queue_state (QueueStateMcpTools): configured vs. effective
parallel-slot count (via QueueService.GetSlotCountsAsync, extracted from
the former GetEffectiveMaxParallelAsync), active slots with taskId +
startedAt including the run_task_now override slot, and queued tasks in
pick order -- so a caller can observe queue occupancy instead of inferring
it from maxParallelExecutions.

tests/ClaudeDo.Worker.Tests/External/TaskWaitMcpToolsTests.cs

@@ -123,7 +123,7 @@ public sealed class TaskWaitMcpToolsTests : IDisposable
     [Fact]
     public void MaxTimeoutSeconds_StaysComfortablyUnderMcpToolTimeout()
     {
-        // InteractiveLaunchSpecService sets MCP_TOOL_TIMEOUT=200000ms for the list handler.
-        Assert.True(TaskWaitMcpTools.MaxTimeoutSeconds < 200);
+        // ClaudeProcess / InteractiveLaunchSpecService set MCP_TOOL_TIMEOUT=930000ms.
+        Assert.True(TaskWaitMcpTools.MaxTimeoutSeconds < 930);
     }
 }