Walk an operand below .zfs or a symlink on its own (closes #142)

An operand under another was dropped as covered by it even when a
directory between them was named .zfs or was a symlink. The walk of
the outer operand enters neither, so the files under the inner operand
went unscanned and their records were deleted. walkReaches now reports
such an operand as not reached, so pruneRoots keeps it and walks it on
its own. README lists both cases with the others.

Judgement call: the new constant zfsDirName replaces the .zfs literal
in operandWarning and subdirJob too, because goconst rejects a third
copy.

Model: opus-5-5

TODO.md

@@ -29,6 +29,12 @@
 
 # Completed Steps
 
+- an operand under another is walked on its own when a directory between them,
+  the inner operand included, is named `.zfs` or is a symlink. The walk of the
+  outer operand does not reach it then. `scan` now records the files below it
+  and no longer deletes their records (2026-10-26,
+  https://git.eeqj.de/sneak/sfdupes/issues/142)
+
 - a file or directory removed while the scan runs is not an error, in the walk
   or in the hash phase. The scan prints no line for it and does not count it as
   skipped. When the first of several hard links to a file is gone, the hash