fix(worker): preview_merge braucht einen runVerify-Parameter wie preview_merge_set

preview_merge baute bisher immer, sobald die Liste ein Verify-Kommando
konfiguriert hatte -- anders als das Geschwister-Tool preview_merge_set,
dessen runVerify-Parameter per Default false ist. Ein einzelnes preview_merge
im Merge-Helper-Recheck stiess dadurch einen ungewollten Scratch-Build an.

runVerify (Default false) jetzt symmetrisch bei preview_merge ergaenzt,
Description-Text und die Merge-Helper-Prompt-Doku angepasst.

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

docs/explore-notes/review-merge.md

@@ -184,9 +184,9 @@ detached-HEAD scratch worktree under the OS temp dir (`GitService.WorktreeAddDet
 is always removed afterward (`finally`, non-cancellable cleanup). No verify command configured, or
 `runVerify=false`, reproduces the pre-existing preview exactly — no delay, no scratch worktree.
 
-Wired into `ExternalMcpService`: `preview_merge` (single task) always requests a verify run when the
-list has a command configured; `preview_merge_set` only does when its `runVerify` parameter is
-explicitly set (default `false`) — a set preview never starts N builds unasked. The Hub's
+Wired into `ExternalMcpService`: both `preview_merge` (single task) and `preview_merge_set` only
+request a verify run when their `runVerify` parameter is explicitly set (default `false`) — a
+preview never starts a build unasked. The Hub's
 `PreviewMerge` (the UI's live mergeability indicator) always passes `runVerify: false`, since
 running a build on every poll would be a bad regression; `MergePreviewDto` carries the
 verify fields anyway so a future UI entry point can opt in. Result fields: `VerifyExitCode` (null =