space: the diff's clock runs inside sudo, so zfs is killed too

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

PLAN.md

@@ -356,10 +356,12 @@ something long in one, switch away and back, refresh — it's all still there.
   snapshots, the scan records the newest snapshot of each dataset at start (`bases`), and the
   next one runs `zfs diff -H -F <base>` per dataset: only the directories it names are
   read, their ancestors kept but looked into, everything else kept wholesale without a
-  stat. The diffs run side by side and one is given four minutes (its process group is
-  killed, sudo and zfs both), after which that dataset is walked by mtime instead — on
-  `tank`, `immich` changes constantly and its diff ran past twenty minutes the first time,
-  longer than walking it. Elsewhere (ext4, or a dataset with no snapshot) a directory whose mtime — to the
+  stat. The diffs run side by side and one is given three minutes — `timeout -s KILL`
+  inside sudo, since Debian's sudo gives the command its own session and a process-group
+  kill from outside never reached zfs — after which that dataset is walked by mtime
+  instead. On `tank` a diff is metadata-bound like the walk: 8 s to 3 min per dataset for
+  a handful of changes, and `immich`, which changes constantly, ran past twenty minutes
+  the first time. A refresh of `tank` took 4 min 19 s against 7 min for the full scan. Elsewhere (ext4, or a dataset with no snapshot) a directory whose mtime — to the
   nanosecond — is unchanged keeps its list and only its kept files are stat'ed again, since
   a file can grow without its directory noticing. A **cancelled** scan keeps what it walked,
   marks the folders it never got to (`partial`, "not yet read" in the tree) and **Resume**