Walk an operand nested on another filesystem with -x (closes #106)

With -x, an operand under another operand is kept when it is a
directory on a different filesystem than the deepest kept operand
above it, or a regular file in such a directory, because that
operand's walk then does not reach it; it is walked on its own. A
regular file is judged by its directory, since the walk checks
devices only on directories. Below a kept operand, the rule that keeps
the records under a directory -x did not enter applies only to
directories its own walk did not enter, so the records of files gone
from it are deleted.

The new tests stub the devices and share their scan steps with the
test for #99, whose comment no
longer claims it runs every phase. The startWalk comment is rewrapped.

Model: opus-5-5

README.md

@@ -398,7 +398,10 @@ results do not depend on the working directory. All operands belong to a single
 scan and are enumerated concurrently: every operand seeds the shared walk worker
 pool. Overlapping operands are harmless — an operand that duplicates another or
 lies under another is dropped before walking, so every file is reached exactly
-once and produces one database record.
+once and produces one database record. With `-x`, though, an operand under
+another one is kept and walked on its own when it is a directory on a different
+filesystem than the operand covering it, or a regular file in such a directory,
+because the walk of the covering operand does not reach it.
 
 An operand that is a symlink (never followed, not even as an operand), socket,
 FIFO, or device node, or a directory named `.zfs`, is not scanned. `scan` prints
@@ -451,7 +454,8 @@ operands:
   directory is on another filesystem than its operand counts as outside the
   scanned operands: it is not deleted, and its size joins the size census. A
   filesystem mounted under an operand can therefore be scanned on its own
-  schedule into the same database.
+  schedule into the same database. Records below an operand at or inside such a
+  directory are not kept this way, since that operand's own walk verifies them.
 
 `scan` runs **four sequential phases over the whole scan**. Parallelism lives
 inside each phase; batched database writes begin during the hash phase: