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

With -x, an operand under another operand is kept and walked on its
own when the walk of the deepest kept operand above it cannot reach
it: some directory from it (from its directory, for a regular file) up
to but not including that operand is on a different filesystem than
that operand. Below a kept operand, the rule keeping records under a
directory -x did not enter covers only directories its own walk did
not enter, so records of files gone from it are deleted.

The new tests stub the devices and share their scan steps with the
test for #99. Comments and
README sentences on operands dropped before the walk now also hold
with -x.

Model: opus-5-5

README.md

@@ -398,7 +398,11 @@ 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 any directory from it (from its
+directory, for a regular file) up to but not including the operand covering it
+is on a different filesystem than that operand, because that operand's walk does
+not enter such a directory and so 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
@@ -407,9 +411,8 @@ drops it from the scanned operands before reading the database. Another operand
 beneath it is still scanned. The records stored beneath it are not deleted: they
 are treated like any other record outside the scanned operands, including the
 content-phase exception below. If it lies under another operand, they are under
-that operand instead, and are deleted like any other record there that this scan
-did not verify. This is not an error: a scan whose every operand is dropped
-walks nothing and exits 0.
+that operand instead, and are treated like any other record there. This is not
+an error: a scan whose every operand is dropped walks nothing and exits 0.
 
 `scan` synchronizes the database with the filesystem state under the scanned
 operands:
@@ -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:
@@ -518,17 +522,19 @@ Rules for the walk:
 - Filesystem boundaries are crossed by default. With `-x` (long form
   `--one-file-system`, following the GNU `du`/`rsync` convention), never descend
   into a directory on a different filesystem than its `PATH` operand; each
-  operand is bounded by its own filesystem. The records below such a directory
-  count as outside the scanned operands, as described in "`scan` mode" above:
-  they are not deleted, and their sizes join the size census.
+  operand is bounded by its own filesystem. The records below such a directory,
+  unless they lie below an operand at or inside that directory, count as outside
+  the scanned operands, as described in "`scan` mode" above: they are not
+  deleted, and their sizes join the size census.
 - On any per-path error (permission denied, file vanished between passes,
   unreadable): print a one-line warning to stderr, skip the path, and continue.
   Per-file errors never abort the run; the final summary reports how many were
   skipped. As specified above, a skipped path that has a database record from an
   earlier scan loses that record, unless it failed only in the content phase, or
-  is an operand dropped before the database was read that lies under no other
-  operand; an unreadable directory subtree likewise loses its records (accepted:
-  the database mirrors what the latest scan could actually verify).
+  is an operand dropped before the database was read whose record counts as
+  outside the scanned operands; an unreadable directory subtree likewise loses
+  its records (accepted: the database mirrors what the latest scan could
+  actually verify).
 
 Concurrency: the walk phase (which also stats files), the hash phase, and the
 content phase each use a worker pool of `--workers` workers (default