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.

src/ClaudeDo.Worker/Runner/ClaudeProcess.cs

@@ -40,9 +40,11 @@ public sealed class ClaudeProcess : IClaudeProcess
             psi.ArgumentList.Add(arg);
 
         // Claude Code caps HTTP MCP tool calls at 60 s unless MCP_TOOL_TIMEOUT is raised.
-        // The in-task AskUser tool blocks up to 3 min waiting for the user, so lift the cap
-        // (with margin) or that wait would be killed early. Harmless for every other tool.
-        psi.Environment["MCP_TOOL_TIMEOUT"] = "200000";
+        // wait_for_task_change blocks up to TaskWaitMcpTools.MaxTimeoutSeconds (900 s) and the
+        // in-task AskUser tool blocks up to 3 min waiting for the user, so lift the cap well
+        // past the longer of the two (with margin) or that wait would be killed early. Harmless
+        // for every other tool. Keep in sync with InteractiveLaunchSpecService's MCP_TOOL_TIMEOUT.
+        psi.Environment["MCP_TOOL_TIMEOUT"] = "930000";
 
         using var process = new Process { StartInfo = psi };
         process.Start();