docs: record the verify-gate reach and the NumericUpDown null trap

review-merge: worktree-less approvals run the gate too, and all three UI merge
entry points handle verify_failed explicitly.
Ui gotchas: NumericUpDown.Value is decimal? and nulls while the box is empty.

docs/explore-notes/review-merge.md

@@ -65,7 +65,15 @@ allowed to reach `Done`.
 On failure `MergeResult.Status` comes back `TaskMergeService.StatusVerifyFailed`
 (`"verify_failed"`) with an output excerpt in `ErrorMessage`. This flows through
 `MergeResultDto` (hub) and `ReviewTaskResult` (`review_task`) unchanged, because both already
-treat any non-`blocked`/`conflict` status generically.
+treat any non-`blocked`/`conflict` status generically. All three UI merge entry points handle it
+explicitly (detail-pane Approve, merge modal, worktrees batch) — a generic fallback there showed
+the raw status string instead of the failure.
+
+**Worktree-less approvals are gated too.** A task with no active `WorktreeEntity` — a sandbox run,
+or a list-handler task that commits straight into `list.WorkingDir` — skips the merge entirely,
+but `ApproveAndMergeAsync` still runs the verify command (same per-repo gate, working dir =
+`list.WorkingDir`) before the task may reach `Done`. Without that, the run that lands the most on
+the target branch at once would be the one run nothing checks.
 
 **Serialization:** a process-wide `ConcurrentDictionary<string, SemaphoreSlim>` keyed by
 `list.WorkingDir` serializes `MergeAsync` / `ContinueMergeAsync` (git ops + verify) per repo,