Name the database each command uses on stderr (closes #111)

scan, report and trees now print one line on stderr before anything
else, naming the database as an absolute path and saying whether the
path is the default or comes from SFDUPES_DATABASE; scan also says when
no database file exists yet. report and trees print it before opening
the database, so a missing-database error follows it. databasePath in
db.go now returns the absolute path and its source, and every command
uses that absolute path throughout, so errors and the lock file name it
too. README "Database" lists when scan writes each file, from the lock
file to the -wal and -shm files going away.

Unverified: the line on a terminal has no test of its own; it is
printed before any progress display, the same way in both cases.

Model: opus-5-5

README.md

@@ -96,10 +96,11 @@ As a file `/etc/cron.d/sfdupes`:
   the first scan. To keep it elsewhere, set
   `SFDUPES_DATABASE=/path/to/db.sqlite` before the command on the same line.
 - `scan` writes nothing to stdout. Its stderr, appended here to
-  `/var/log/sfdupes.log`, holds a plain progress line as each phase starts and
-  then at most every 5 seconds, a warning for each path it skips, and the
-  summary line (see "Progress" and "`scan` mode"). The log grows with every
-  scan; rotate it like any other.
+  `/var/log/sfdupes.log`, holds a first line naming the database (see
+  "Database"), a plain progress line as each phase starts and then at most every
+  5 seconds, a warning for each path it skips, and the summary line (see
+  "Progress" and "`scan` mode"). The log grows with every scan; rotate it like
+  any other.
 - Skipped paths do not fail a scan: it still exits 0, and cron sends nothing. A
   scan that fails, or is stopped by `SIGINT` or `SIGTERM`, exits 1 with the
   reason among the last lines of the log; `tail` prints them, and cron mails
@@ -266,6 +267,21 @@ All three subcommands operate on a single SQLite database file:
   command-line flag. The path names the file exactly, whatever characters it
   holds (`?`, `#` and `%` included); a relative path is relative to the working
   directory.
+- Each subcommand first prints one line on stderr naming the database it uses,
+  before anything else it prints (progress displays included), whether or not
+  stderr is a terminal. The line gives the path made absolute against the
+  working directory, escaped like the paths in a report (see "Report output
+  format"), and says where the path came from:
+
+    ```
+    scan: new database /var/lib/sfdupes/db.sqlite (default)
+    trees: database /srv/tmp/sfdupes/db.db (from SFDUPES_DATABASE)
+    ```
+
+    `scan` says `new database` when no file is at that path as it starts.
+    `report` and `trees` print the line before they open the database, so the
+    error for a missing database comes after it.
+
 - `scan` creates the database (and its parent directory) on first use. `report`
   and `trees` require an existing database; a missing database file is a fatal
   error (exit 1) telling the user to run `scan` first.
@@ -304,6 +320,20 @@ All three subcommands operate on a single SQLite database file:
   in WAL mode until the next scan. `report` writes each row as it reads it, so
   it is still reading while its output is paused (a pager, a stalled pipe), and
   a `scan` started then fails after the busy timeout.
+- A `scan` writes to the database and the files beside it at these points (its
+  phases are described under "`scan` mode"):
+    - As it starts, before the walk: the directory, an empty database file and
+      the `.lock` file, each only if missing.
+    - Then, still before the walk: the schema, in a new database, and the `-wal`
+      and `-shm` files, which stay beside the database while the scan runs.
+    - While it loads the existing records (`load`) and walks: no records. A
+      first scan's database holds none, however long its walk has run.
+    - During the hash phase: the first records, committed 10,000 at a time.
+    - In the update phase: the rest of the hashed records, the records for
+      size-unique files, and the deletions.
+    - In the content phase: content hashes, again committed 10,000 at a time.
+    - At the end, as it closes the database: the `-wal` and `-shm` files go
+      away, unless a report still has the database open (see above).
 - `report` and `trees` open the database read-only and need only read access to
   the database file, and no write access to its directory. While the database is
   in WAL mode they also read the `-wal` and `-shm` files beside it, which SQLite