feat(worker): PowerUse-Addendum an die Handler-Prompts, Cap aus den Settings

HandoffRoundTracker.Register nimmt den Cap jetzt als Parameter statt aus einer
Konstante; HandoffMcpTools liest ihn pro Aufruf aus app_settings. Werte unter 1
werden auf 1 geklemmt (in WorkerHub UND in Register): der Cap ist das Einzige,
was eine entlaufene Handoff-Kette begrenzt, "0 = unbegrenzt" darf kein Aufrufer
waehlen koennen.

InteractiveLaunchSpecService.ComposeHandlerPromptAsync haengt das PowerUse-
Addendum an den Phasen-Prompt, aber nur wenn globaler Schalter und Listen-Opt-in
beide gesetzt sind. Bewusst ein Addendum statt einer zweiten Prompt-Garnitur:
die gemeinsamen 95% bleiben an einer Stelle, und ein Run ohne PowerUse bekommt
einen byte-identischen Prompt wie vorher. Das Addendum ist als Override der
interaktiven Regeln formuliert (nie fragen, entscheiden und protokollieren;
Konflikte loesen oder abbrechen, nie im Tree liegen lassen; Arbeit ernten, wenn
eine Runde sonst leer laeuft).

Drei Tests pinnen alle vier Ecken des UND, weil die Sicherheitsaussage des
Features genau daran haengt.

src/ClaudeDo.Worker/External/HandoffMcpTools.cs

@@ -1,7 +1,9 @@
 using System.ComponentModel;
+using ClaudeDo.Data;
 using ClaudeDo.Data.Repositories;
 using ClaudeDo.Worker.Hub;
 using ClaudeDo.Worker.Runner;
+using Microsoft.EntityFrameworkCore;
 using ModelContextProtocol.Server;
 
 namespace ClaudeDo.Worker.External;
@@ -17,12 +19,18 @@ public sealed class HandoffMcpTools
     private readonly TaskRepository _tasks;
     private readonly HubBroadcaster _broadcaster;
     private readonly HandoffRoundTracker _rounds;
+    private readonly IDbContextFactory<ClaudeDoDbContext> _dbFactory;
 
-    public HandoffMcpTools(TaskRepository tasks, HubBroadcaster broadcaster, HandoffRoundTracker rounds)
+    public HandoffMcpTools(
+        TaskRepository tasks,
+        HubBroadcaster broadcaster,
+        HandoffRoundTracker rounds,
+        IDbContextFactory<ClaudeDoDbContext> dbFactory)
     {
         _tasks = tasks;
         _broadcaster = broadcaster;
         _rounds = rounds;
+        _dbFactory = dbFactory;
     }
 
     [McpServerTool, Description(
@@ -33,7 +41,8 @@ public sealed class HandoffMcpTools
         "after triage) or \"merge\" (review + merge; the normal handoff after wait) -- \"wait_final\"/" +
         "\"merge_final\" are only for a merge session that started reruns and must eventually stop the " +
         "chain instead of restarting again. An unrecognized value is rejected. This handoff chain is " +
-        "capped server-side at four handoffs (i.e. two " +
+        "capped server-side at a configurable number of handoffs (the ListHandlerMaxHandoffs setting, " +
+        "4 by default, i.e. two " +
         "full wait/merge cycles) for a given handler task: once reached, a \"wait\"/\"merge\" request is " +
         "silently coerced to its \"_final\" counterpart instead (check the result's coerced field), and " +
         "any handoff at all after a merge_final round for this task throws. The current tile stays " +
@@ -59,7 +68,10 @@ public sealed class HandoffMcpTools
             _ = await _tasks.GetByIdAsync(id, cancellationToken)
                 ?? throw new InvalidOperationException($"Task {id} not found.");
 
-        var round = _rounds.Register(taskId, nextPhase);
+        await using var ctx = await _dbFactory.CreateDbContextAsync(cancellationToken);
+        var maxHandoffs = (await new AppSettingsRepository(ctx).GetAsync(cancellationToken)).ListHandlerMaxHandoffs;
+
+        var round = _rounds.Register(taskId, nextPhase, maxHandoffs);
         if (round.Rejected)
             throw new InvalidOperationException(round.Error);