Keep a variant's accounting row when its file cannot be read (closes #340)

The reconciliation pass dropped a variant's accounting row on any error
reading its file's size, and logged every such file as missing. A file
still on disk then had no row, so eviction no longer counted it against
cache_max_bytes. Now only a missing file (ErrNotFound, which
FileStore.Size returns for it) loses its row, with the same info line.
Any other error keeps the row and logs a warning naming the variant key
and the error, and the pass goes on to the next key. README.md says so
under Storage.

Model: opus-5-5

README.md

@@ -252,6 +252,10 @@ less than ten times as long after the last look ended as that look took. After a
 look that took one minute, the next one starts 10 to 15 minutes after that look
 ended.
 
+Each look also drops the rows of variants whose files are missing. When pixa
+cannot read a variant file's size for another reason, it keeps the variant's
+row. It logs a warning naming the variant key and the error.
+
 pixa's target is 1-5k r/s, which has not been measured at that rate (see Load
 Test). Toward it, a cache hit opens the variant's file and nothing else, and
 makes no database call. The content type comes from the file's first bytes,