Never scan an operand inside a .zfs directory (closes #142)

An operand inside a directory named .zfs was walked, because the
operand check looked only at the operand's own name. The check now
also looks at every directory above the operand. Such an operand gets
a warning, counts as skipped and is not walked, whether given alone or
under another operand. The check runs before overlapping operands are
pruned, so an operand under another one still gets its warning.

The test for an operand named .zfs now writes its record beneath .zfs
straight into the database, since no scan stores one there any more.

Judgement call: a path component named .zfs counts whatever it is, a
symlink included.

Model: opus-5-5

README.md

@@ -461,17 +461,23 @@ exclude, is not on a persistent filesystem (see "Rules for the walk"), or, with
 `-x`, 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
-a one-line warning naming the path and what it is, counts it as skipped, and
-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. If it lies under
-another operand, they are under 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. An operand that is not on a persistent filesystem
-(see "Rules for the walk") is dropped the same way. The line `scan` prints for
-it is not a warning, though, and it is not counted as skipped.
+An operand is not scanned when it is:
+
+- a symlink, which `scan` never follows, not even as an operand;
+- a socket, FIFO or device node;
+- at or inside a directory named `.zfs`.
+
+This holds even when the operand lies under another operand. `scan` prints a
+one-line warning naming the path and what it is, counts it as skipped, and drops
+it from the scanned operands before reading the database. An operand beneath a
+symlink operand is still scanned. The records stored beneath the dropped operand
+are not deleted: they are treated like any other record outside the scanned
+operands. If it lies under another operand, they are under 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. An operand that is not on a
+persistent filesystem (see "Rules for the walk") is dropped the same way. The
+line `scan` prints for it is not a warning, though, and it is not counted as
+skipped.
 
 `scan` synchronizes the database with the filesystem state under the scanned
 operands: