feat(2.8.0): Pruefen duerfen, ohne beheben zu duerfen

Der Unterschied zwischen "ich habe es behoben" und "der Fix eines anderen
traegt" ist das Rueckgrat des Pruefverfahrens aus 2.6.1. Er stand bisher nur in
der Anleitung - im Datenbestand und in den Rechten kam beides gleich an.

RECHTE

bugtracker:manage war ein einziger Schreib-Scope: Wer eine Nachpruefung
bestaetigen durfte, durfte auch resolve, update, bulk_update und die Roadmap
umschreiben. Fuer einen Pruefstand ist das zu viel - und wer einen Fix schreibt
und ihn selbst abnimmt, prueft gegen die Erwartung, die er beim Schreiben hatte.

bugtracker:verify deckt jetzt ab, was ein Pruefer braucht: next, claim, release,
comment, confirm, report. Nicht mehr. manage schliesst es ein (IMPLIED_SCOPES),
vorhandene Token verlieren nichts.

"status" bleibt bewusst bei manage. Darueber liesse sich sonst jeder Zustand
setzen, auch "resolved" - der Umweg um genau diese Trennung.

DATENBESTAND

Eine bestaetigte Nachpruefung war nicht von "jemand hat das Item zugemacht" zu
unterscheiden: dc-testkit confirm setzte status=closed und schrieb den Rest in
einen Kommentar. Damit war die eine Frage, fuer die das Verfahren gebaut ist,
nicht beantwortbar - wurde dieses Item je gegen ein ausgeliefertes Paket
geprueft? Ein Kommentartext laesst sich nicht zaehlen und nicht filtern.

Migration 017 legt verified_at, verified_in_build und verified_by an. Kein
eigener Status daneben: Ein bestaetigtes Item IST geschlossen, die Bestaetigung
ist eine Eigenschaft dieses Abschlusses. Ein zweiter Wert waere dieselbe Falle,
die 016 beim is_roadmap-Flag vermieden hat.

verified_in_build steht neben resolved_in_build, weil beide verschiedene Fragen
beantworten und auseinandergehen koennen - genau das ist der interessante Fall.
Das eine ist die Behauptung des Behebenden, das andere die Beobachtung des
Pruefenden.

confirm laesst sich nur auf Items anwenden, die jemand als behoben ausgegeben
hat (resolved, awaiting_verification, in_verification, fix_insufficient). Ein
offenes Item zu "bestaetigen" waere ein Schliessen mit schmueckendem Beiwort -
und stuende hinterher als geprueft in einer Statistik, die genau das misst.
Antwort: 409 not_verifiable.

MCP

dc_confirm. Der Adapter hatte dc_next_task und dc_resolve, aber keinen Weg, eine
Nachpruefung abzuschliessen; dc_comment kennt nur action_taken, keinen Status.
Ein Pruefagent ueber MCP konnte einen Auftrag uebernehmen und dann nichts damit
anfangen. 16 Werkzeuge statt 15.

TESTKIT

dc-testkit confirm nutzt die Aktion und schickt die gepruefte Fassung als Feld.
Antwortet der Server mit 404, faellt es auf den alten Weg zurueck und sagt, dass
die Fassung dann nur im Kommentar landet.

Drei neue e2e-Faelle: dass confirm die gepruefte Fassung festhaelt, dass es nur
dort geht, wo es etwas zu bestaetigen gibt, und dass ein verify-Token
kommentieren, aber nicht beheben darf. 147 bestanden, 0 uebersprungen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

public/testkit/dc-testkit.sh

@@ -1624,16 +1624,48 @@ cmd_confirm() {
 
     build="$(detect_build || true)"
 
-    local text="Nachpruefung bestanden${build:+ (geprueft gegen $build)}."
-    [ -n "$note" ] && text="$text $note"
-
+    # Eigene Aktion, nicht "status=closed" mit schmueckendem Kommentar.
+    #
+    # Bis 2.7.1 war es genau das - und damit war eine bestaetigte Nachpruefung
+    # im Datenbestand nicht von "jemand hat das Item zugemacht" zu
+    # unterscheiden. Die eine Frage, fuer die das Verfahren gebaut ist ("wurde
+    # das gegen ein ausgeliefertes Paket geprueft?"), war nicht beantwortbar,
+    # weil die Antwort in einem Kommentartext stand.
+    #
+    # Die gepruefte Fassung geht deshalb als Feld mit, nicht im Fliesstext:
+    # Der Server haelt sie in verified_in_build und kann sie gegen
+    # resolved_in_build stellen. Gehen die beiden auseinander, wurde gegen
+    # etwas anderes geprueft als angekuendigt - und das sieht man dann.
     local payload
-    payload=$(json_object status closed notes "$text")
+    payload=$(json_object verified_in_build "${build:-}" notes "$note")
 
-    api POST "/api/bugtracker/v1/manage?action=status&id=$id" "$payload" \
-        || die "Bestaetigung nicht angenommen: $(api_error)"
+    if ! api POST "/api/bugtracker/v1/manage?action=confirm&id=$id" "$payload"; then
+        case "$API_STATUS" in
+            404)
+                # Ein Server vor 2.8.0 kennt die Aktion nicht. Der alte Weg
+                # bleibt richtig - er sagt nur weniger.
+                warn "Dieser Server kennt 'confirm' noch nicht - alter Weg (status=closed)."
+                warn "  Die gepruefte Fassung landet dann nur im Kommentar."
 
-    ok "Item #$id bestaetigt und geschlossen${build:+ - geprüft gegen $build}"
+                local text="Nachpruefung bestanden${build:+ (geprueft gegen $build)}."
+                [ -n "$note" ] && text="$text $note"
+
+                api POST "/api/bugtracker/v1/manage?action=status&id=$id" \
+                    "$(json_object status closed notes "$text")" \
+                    || die "Bestaetigung nicht angenommen: $(api_error)"
+                ;;
+            409)
+                # Kein Fehler des Aufrufers, sondern eine Aussage ueber das
+                # Item: Da ist nichts, was sich bestaetigen liesse.
+                die "Nichts zu bestaetigen: $(api_error)"
+                ;;
+            *)
+                die "Bestaetigung nicht angenommen: $(api_error)"
+                ;;
+        esac
+    fi
+
+    ok "Item #$id bestaetigt und geschlossen${build:+ - geprueft gegen $build}"
 }
 
 cmd_comment() {