Mercury 3 vs GPT-6 Luna and Claude Haiku 5.5 on 10 real Rust changes

Reference PR: Add --log-level; make it and -v override RUST_LOG env var (#89). Snapshot at parent 0949eaa.

Defects found by the reviewing agent:

• Mercury 3
  • minor Conflict between -v and --log-level not detected when they are split across the subcommand
• GPT-6 Luna
  • minor Conflict between -v and --log-level not detected when they are split across the subcommand
• Claude Haiku 5.5
  • minor Conflict between -v and --log-level not detected when they are split across the subcommand
  • minor Docstring and summary claim clap guarantees the two flags never both appear

Reviewing agent's one-line note per run (its opinion, not a measurement):

Mercury 3

Correct, reference-like implementation, but its five tests skip the replace-not-merge direction, -vv, the warn default, global placement and help output.

GPT-6 Luna

Correct implementation with good test coverage (including global placement and the suppression direction), slightly less thorough help text and no invalid-value test.

Claude Haiku 5.5

Clean, well-documented implementation that folds -v into a single explicit level, with a solid test set including the replace-not-merge direction and exit-code checks.

Full unblinded review: reviews/c01-loglevel.md (candidate letters: A = Claude Haiku 5.5, B = Mercury 3, C = GPT-6 Luna).

Exact task text (appended to the shared preamble in the Method section):

Add an explicit `--log-level` flag, and make the command-line logging flags win over `RUST_LOG`.

Right now `-v`/`-vv` only set the *default* log level: if `RUST_LOG` is set in the environment it silently wins, so
`RUST_LOG=warn treeward -v init` prints nothing at info level. That's backwards for a CLI; whatever I type on the command
line should beat whatever happens to be in my environment.

What I want:

- A new global flag `--log-level <LEVEL>` accepting `error`, `warn`, `info`, `debug`, `trace`. Like `-C` and `-v` it
  should work as a global option (e.g. `treeward --log-level info init`).
- If `--log-level` or `-v`/`-vv` is given, it decides the level and `RUST_LOG` is ignored entirely (not merged with it).
  `-v` stays info, `-vv` and above stay debug.
- With neither flag, keep today's behavior: honor `RUST_LOG` if set, otherwise default to `warn`.
- `--log-level` together with `-v` is a usage error (non-zero exit), not "one silently wins".
- `treeward --help` should document both flags and say that they take precedence over `RUST_LOG`.

Reference PR: bugfix: fingerprint validation misses repeated edits (#83). Snapshot at parent c8b8189.

Defects found by the reviewing agent:

• Mercury 3
  • minor Default `status` now reads/checksums every added and M? file, so it is no longer metadata-only and fails on unreadable changed files
  • minor User-facing docs still promise a metadata-only default status after the change made it read content
• GPT-6 Luna
  • minor Default `status` now checksums added and M? files; unreadable changed files make `status` fail
  • minor README rewrite dropped the 'two purposes' (TOCTOU / idempotency) list from 'Fingerprinting in depth'
• Claude Haiku 5.5
  • minor Removed entries hash ObservedEntry::Absent only, so the prior ward state is not bound
  • minor README edit is not dprint-formatted (CI requires dprint fmt)

Reviewing agent's one-line note per run (its opinion, not a measurement):

Mercury 3

Strong, well-tested fix that binds full old->new ward state, but it quietly turns default `status` into a content-reading command and leaves the docs claiming otherwise.

GPT-6 Luna

Complete, well-encoded fix with good policy-matrix integration tests and honest, thorough docs for its main cost: default status now reads changed files.

Claude Haiku 5.5

Clean, reference-like fix that preserves the cheap default status, held back by thin unit-only tests, an unbound removal payload and a dprint failure.

Full unblinded review: reviews/c02-fp-repeated-edits.md (candidate letters: A = Mercury 3, B = Claude Haiku 5.5, C = GPT-6 Luna).

Exact task text (appended to the shared preamble in the Method section):

`update --fingerprint` (and `init --fingerprint`) doesn't actually guarantee what the help text promises: that if
anything changes between `status` and the update, the fingerprint won't match. It's easy to sneak a change through:

    treeward init
    echo bbbbb > file.txt          # first edit
    treeward status                # shows "M? file.txt" and a Fingerprint
    echo ccccc > file.txt          # second edit, after I reviewed
    treeward update --fingerprint <fp from above>   # succeeds, records content I never reviewed

The same thing happens with `--verify` (the file is `M` both times), with a newly added file that is edited again after
`status`, and with a symlink that is re-pointed after `status`. As long as the path and its status letter stay the same,
the fingerprint is accepted.

Please fix this so the fingerprint binds the exact state that `status` reported for each changed entry, and a later
change to any of those entries makes `init`/`update --fingerprint` fail with the existing fingerprint-mismatch error
(and write nothing).

Also make sure the fingerprint can't be fooled through file names: two different change sets must never produce the
same fingerprint, whatever characters the names contain (`|`, newlines, etc. are all legal in names).

Must keep working: `status` followed by `init`/`update --fingerprint` with matching flags and no intervening change is
accepted, for every kind of change (added/removed/modified files, directories, symlinks) under the default policy,
`--verify`, and `--always-verify`. A metadata-only touch with unchanged content must still be accepted the same way it
is today.

Reference PR: fix: write ward files deepest-first and report partial updates (#147). Snapshot at parent f5f2c3d.

Defects found by the reviewing agent:

• Mercury 3
  • critical Rollback deletes a newly created child ward whose pre-existing parent ward was already rewritten to list it
  • minor -v 'Updated N ward files' listing order changed (sorted by .treeward path, not directory)
• GPT-6 Luna no defects found
• Claude Haiku 5.5
  • major Staging keeps one open NamedTempFile per changed ward, so large runs exhaust file descriptors
  • minor -v listing of a successful run is now in deepest-first commit order and disagrees with --dry-run
  • minor Recovery advice names `treeward update` even when init failed

Reviewing agent's one-line note per run (its opinion, not a measurement):

Mercury 3

Correct deepest-first ordering undermined by a best-effort rollback that, in a realistic case, recreates exactly the parent-vouches-for-missing-child state the task forbids.

GPT-6 Luna

Reference-equivalent deepest-first design with a more precise written count and recovery advice that works for both init and update; only nit is a hand-edited CHANGELOG.

Claude Haiku 5.5

Clean two-phase stage/commit that handles permission failures well, but holding every temp file open breaks init/update on large trees and the -v order changed.

Full unblinded review: reviews/c03-partial-writes.md (candidate letters: A = Mercury 3, B = GPT-6 Luna, C = Claude Haiku 5.5).

Exact task text (appended to the shared preamble in the Method section):

When `init` or `update` fails partway through writing ward files (permission denied, disk full, ...), it leaves the tree
in a confusing state and tells the user nothing useful about it.

Repro:

    treeward init                    # tree with file.txt
    mkdir newsubdir; echo hi > newsubdir/file2.txt
    chmod 555 newsubdir
    treeward update                  # fails with "Permission denied"
    chmod 755 newsubdir
    treeward status                  # now shows "A  newsubdir/file2.txt" instead of "A  newsubdir"

The root `.treeward` was already rewritten to say `newsubdir` is tracked, even though `newsubdir/.treeward` was never
created. So the change I reviewed ("new directory newsubdir") has turned into something different, and the error only
said "Permission denied" without mentioning that some ward files were written and others weren't.

I don't need the whole set of ward files to be written atomically (that would need a journal and I don't want one). What
I do want:

- After a failure at any point in the write phase, no ward file written by the run may describe a subdirectory whose
  own `.treeward` is missing or out of date. `status` must keep reporting the unfinished work the way it did before the
  failed run (in the repro: `A  newsubdir`). This has to hold for deeper trees too, wherever the failure happens.
- The error (still a fatal error, exit 255) must say how far the run got, as "N of M", e.g. "wrote 1 of 3 changed ward
  files", and that fixing the cause and re-running finishes the job. If the partial write means a fingerprint taken
  before the run can no longer be used, say so and tell the user what to do instead.
- Re-running after fixing the cause must converge to a clean `status`.
- Successful runs and `--dry-run` behave exactly as before.

Reference PR: fix: abort when a file changes between listing and checksumming (#149). Snapshot at parent ff59c34.

Defects found by the reviewing agent:

• Mercury 3
  • minor checksum_file docstring truncated mid-sentence
  • minor Production doc links to a #[cfg(test)]-only item
  • minor Race integration tests are sleep-timed and probabilistic
• GPT-6 Luna
  • minor Detailed Behavior/Errors docs for the checksum function deleted, not moved
• Claude Haiku 5.5 no defects found

Reviewing agent's one-line note per run (its opinion, not a measurement):

Mercury 3

Correct and complete fix with an end-to-end race test, let down by a timing-based test design and a truncated docstring.

GPT-6 Luna

Correct fix with deterministic walk-level tests covering every checksum site and the plain-status exception, marred only by deleted function docs.

Claude Haiku 5.5

Correct fix with a nicely type-enforced API and good docs, but tests only pin the checksum primitive, not the status-walk wiring.

Full unblinded review: reviews/c04-list-read-race.md (candidate letters: A = Mercury 3, B = Claude Haiku 5.5, C = GPT-6 Luna).

Exact task text (appended to the shared preamble in the Method section):

I found a TOCTOU hole in the `status` → `update --fingerprint` workflow under the default (metadata-only) policy. With a
race script I got `update --fingerprint <fp>` to exit 0 and write a ward entry whose sha256 is of content I never
reviewed.

The setup: a tree where two files have pending changes, a large one (`a.big`) and a small one (`z.txt`). I run
`treeward status`, review it, and start `treeward update --fingerprint <fp>`. While `update` is busy checksumming
`a.big`, something edits `z.txt` (new size and mtime). `update` then checksums the edited `z.txt`, records it, and the
fingerprint still matches. The existing "modified during checksumming" protection doesn't fire, because the edit landed
before `z.txt` was opened, not while it was being read. The same goes for newly added files. With `--verify` I believe
the fingerprint already notices, but the default policy is the one people use.

Expected behavior: if a file's size or mtime changes after its directory was listed but before it is checksummed, treat
that exactly like the existing concurrent-modification case. That means a fatal error (exit 255) naming the file, no
retry, and no ward file written. This applies to every command that checksums the file (`init`, `update`, `verify`,
`status --verify`/`--always-verify`), with or without `--fingerprint`. Commands that never read the file, like plain
`status` under the default policy, must not start failing on trees that are being written to.

Reference PR: fix: stop rejecting pre-epoch and far-future directory mtimes (#146). Snapshot at parent 95e4340.

Defects found by the reviewing agent:

• Mercury 3
  • minor Out-of-range dir mtimes collapse to a single None value in the fingerprint, so binding is inconsistent with in-range dirs
• GPT-6 Luna no defects found
• Claude Haiku 5.5 no defects found

Reviewing agent's one-line note per run (its opinion, not a measurement):

Mercury 3

Correct, well-tested fix that keeps representable dir mtimes in the fingerprint and degrades out-of-range ones to a tagged None, at the cost of a small binding inconsistency.

GPT-6 Luna

Correct, exact, unambiguous range-safe encoding of dir mtimes with a solid workflow test, let down by a hand-edited generated CHANGELOG and a thin summary.

Claude Haiku 5.5

Correct exact-i128 encoding that keeps in-range dir fingerprints byte-identical, with precise SPEC/README/doc updates and good unit tests but only one CLI test.

Full unblinded review: reviews/c05-dir-mtime.md (candidate letters: A = Mercury 3, B = GPT-6 Luna, C = Claude Haiku 5.5).

Exact task text (appended to the shared preamble in the Method section):

A tree containing a directory with a pre-1970 mtime cannot be initialized. Restored tar archives and some synced trees
produce these, so this blocks real users. Repro:

```sh
mkdir -p t/old && touch -d '1960-01-01' t/old
treeward -C t init
# ERROR: Status error: mtime of .../t/old is before the UNIX epoch; pre-1970 timestamps are not supported   (exit 255)
```

It is also inconsistent. The same thing happens when such a directory shows up as new inside an already-warded tree
(`status`, `update`, `init`, `--dry-run` all abort), but once the directory has been recorded in its parent's ward file,
`status` passes silently even though the mtime is just as old. Directories with mtimes past the supported ceiling (after
roughly year 2262) behave the same way.

What I want:

- A directory's mtime, whatever its value, never makes `init`, `status`, `update` (with or without `--fingerprint`), or
  `verify` fail, whether the directory is new or already tracked.
- The documented limitation for regular files stays exactly as it is: a regular file with a pre-epoch or out-of-range
  mtime is still a fatal error naming the file, since its mtime is persisted in `mtime_nanos`.
- The `status` → `update --fingerprint` review workflow keeps working for changesets that contain new directories,
  including ones with such mtimes.

Reference PR: fix: escape control characters in stderr diagnostics (#125). Snapshot at parent 37dfeb4.

Defects found by the reviewing agent:

• Mercury 3
  • minor SPEC/summary claim stderr escapes match the stdout listing and are unambiguous; actual ESC/C1/DEL render double-escaped and collide with literal text
• GPT-6 Luna
  • minor No backslash doubling, so escaped stderr output is ambiguous with literal backslash text in names
• Claude Haiku 5.5 no defects found

Reviewing agent's one-line note per run (its opinion, not a measurement):

Mercury 3

Correct central fix at the formatter with good LF/CR CLI tests, marred by a SPEC sentence that overstates the stderr rendering's fidelity and unambiguity.

GPT-6 Luna

Minimal, correct streaming escaper with an accurate SPEC, but it duplicates the existing helper without backslash doubling, leaving ambiguous output.

Claude Haiku 5.5

Best design: a field visitor that makes the shared escape_control the sole escaper, so stderr output is clean, unambiguous and consistent with stdout, backed by thorough tests and an accurate SPEC.

Full unblinded review: reviews/c06-stderr-escape.md (candidate letters: A = Mercury 3, B = GPT-6 Luna, C = Claude Haiku 5.5).

Exact task text (appended to the shared preamble in the Method section):

The `status`/`verify` listing on stdout escapes control characters so a crafted file name can't mess with the terminal,
but stderr has no such protection. Error messages and `-v`/`-vv` logging print file names, directory names, symlink
targets and ward-file contents, and some control characters get through raw. For example, a file name containing a
newline forges extra log lines:

```sh
mkdir t && touch $'t/evil-a\nERROR: forged.txt'
treeward -C t -v init
# INFO: Checksumming .../t/evil-a
# ERROR: forged.txt              <- looks like a real treeward error line
```

A carriage return in a name similarly overwrites what the user sees on the line. The same thing happens with error
lines, e.g. the "unsupported file type" error for a FIFO with such a name, or a corrupt `.treeward` whose entry names
contain control characters.

What I want: nothing treeward prints to stderr, whether error messages or diagnostic logging at any verbosity, contains a
raw control character (C0 including CR, LF and TAB, DEL, or C1 such as U+009B) that came from a scanned name, symlink
target, ward-file field or other runtime data. The only raw newline is the one that ends each message. Show control
characters in some visible escaped form. I don't need a particular rendering, but the offending name has to stay
recognisable in the message. This should hold for every stderr diagnostic, not only the examples above. Usage errors
that clap reports while it is still parsing the command line are out of scope. Exit codes and stdout output must not
change.

Reference PR: fix: reject non-UTF-8 symlink targets when listing a directory (#144). Snapshot at parent bf03f80.

Defects found by the reviewing agent:

• Mercury 3 no defects found
• GPT-6 Luna
  • major Moving the NotInitialized/AlreadyInitialized checks after compute_status(WardUpdate) makes those cheap precondition failures checksum the whole tree first
  • minor Error precedence change is undocumented: unrelated scan errors now mask NotInitialized
• Claude Haiku 5.5 no defects found

Reviewing agent's one-line note per run (its opinion, not a measurement):

Mercury 3

Correct choke-point fix matching the reference, with the most thorough tests (unit, compute_status, 9 CLI cases), marred only by a hand-edited generated CHANGELOG.

GPT-6 Luna

The core fix is right, but an unnecessary reorder in ward_directory makes `update`/`init` checksum the entire tree before reporting not/already initialized.

Claude Haiku 5.5

Clean, minimal reference-equivalent fix with an accurate SPEC entry, but committed CLI coverage is init-only (status/verify/update were checked only by hand, as its summary admits).

Full unblinded review: reviews/c07-symlink-utf8.md (candidate letters: A = Mercury 3, B = GPT-6 Luna, C = Claude Haiku 5.5).

Exact task text (appended to the shared preamble in the Method section):

A symlink whose target isn't valid UTF-8 breaks treeward in a confusing way. Repro (Linux):

```sh
mkdir -p t/sub && echo hello > t/file.txt
ln -s $'bad\xff' t/sub/link
treeward -C t status          # exit 1, lists sub/link as added and prints a fingerprint
treeward -C t init --dry-run  # exit 0, looks fine
treeward -C t init            # exit 255: "ERROR: Ward file error: TOML serialization error: path contains invalid UTF-8 characters"
ls t/.treeward                # ...and the root ward file was written anyway
```

So `status` and the dry run say everything is fine, the real `init` (and `update`) then dies with an error that doesn't
say which entry is the problem, and it leaves ward files half-written. The tree can't be warded until the user finds the
link on their own.

Ward files are TOML, so such a target can't be recorded. I'm fine with that being unsupported, the way non-UTF-8 file
names already are. But it has to be reported properly:

- Every command (`status`, `verify`, `init`, `update`, `update --allow-init`, with or without `--dry-run`) fails with
  the usual fatal exit code (255). This includes a link that's already tracked and gets retargeted.
- The error names the link itself (its path, not the target) and says the problem is that the target isn't UTF-8.
- This happens before any `.treeward` file is written or modified.
- Valid UTF-8 targets, including non-ASCII and dangling ones, keep working as before.

Don't paper over it with a lossy conversion.

Reference PR: fix: refuse a root .treeward that is not a regular file (#148). Snapshot at parent 695ce8d.

Defects found by the reviewing agent:

• Mercury 3
  • minor Unit test path assertion compares against non-canonical root.join(".treeward")
• GPT-6 Luna
  • minor CLI test expects the non-canonical root path in stderr
• Claude Haiku 5.5
  • minor 'valid-target' unit fixture links to an empty file, not a valid ward, and the CLI test omits the symlink-to-valid-ward case

Reviewing agent's one-line note per run (its opinion, not a measurement):

Mercury 3

Correct lstat-based guard with the broadest test matrix, marred by sloppy test code (unused shadowed variables, // instead of ///) and leftover exists() calls.

GPT-6 Luna

Correct and tight fix with full CLI coverage and a help-text correction, but lighter on documentation and has no unit test.

Claude Haiku 5.5

Cleanest implementation: a well-documented root_ward_present helper with clear rationale, regression coverage for the regular-file case, and an accurate summary; its own tests are slightly weaker on the valid-ward-link case.

Full unblinded review: reviews/c08-root-ward-type.md (candidate letters: A = Mercury 3, B = GPT-6 Luna, C = Claude Haiku 5.5).

Exact task text (appended to the shared preamble in the Method section):

treeward gets confused when the root `.treeward` is not a regular file. Two things I hit:

1. A `.treeward` symlink caught in a loop at the root:

   ```sh
   mkdir t && cd t && echo hi > a.txt
   ln -s loop .treeward && ln -s .treeward loop
   treeward update   # "Not initialized (use treeward init to initialize)"
   treeward init     # dies with a raw "Too many levels of symbolic links"
   ```

   So `update` sends me to `init`, and `init` then fails with an OS error.

2. A dangling `.treeward` symlink at the root (`ln -s nowhere .treeward`): `treeward update` succeeds and quietly
   replaces the symlink with a regular ward file.

An integrity tool shouldn't guess here. Whenever anything other than a regular file sits at the root `.treeward` path
(a directory, or a symlink, whether it loops, dangles, or points at a perfectly valid ward file), `init`, `update`, and
`update --allow-init` should all refuse with a fatal error (the usual fatal exit code, 255) and leave that entry
untouched. They should not follow it, read through it, or replace it. The error message should name the `.treeward`
path and say that it is not a regular file. It must not claim the tree is "Not initialized" or "Already initialized".

The normal cases must keep working as they do today: nothing at the root `.treeward` means "Not initialized" for
`update` and a fresh start for `init`, and a regular file means initialized.

Correction: the dangling-symlink repro is wrong for plain update. On the starting commit, update with a dangling .treeward link stops with "Not initialized", because Path::exists() follows the link. The silent replacement happens with update --allow-init. The models received the text as shown.

Reference PR: fix: reject ward files with malformed sha256 fields at load time (#116). Snapshot at parent 6ddf457.

Defects found by the reviewing agent:

• Mercury 3 no defects found
• GPT-6 Luna no defects found
• Claude Haiku 5.5
  • minor ward_directory doc comment still says an existing root is always an AlreadyInitialized error

Reviewing agent's one-line note per run (its opinion, not a measurement):

Mercury 3

Reference-equivalent fix with the broadest spread of tests, but init on a corrupt existing root does not name the entry, the CHANGELOG edit is unwanted, and the summary misdescribes how git-cliff treats it.

GPT-6 Luna

Correct and complete, with init naming the entry and a write-side guard; tests are good but use only one malformed value at the CLI and skip subdirectories, and the hand-edited CHANGELOG is unwanted churn.

Claude Haiku 5.5

Load-boundary validation matching the reference, plus an init fix that names the entry, thorough unit and CLI tests, and an accurate summary; only a stale doc comment.

Full unblinded review: reviews/c09-sha256-validate.md (candidate letters: A = Claude Haiku 5.5, B = GPT-6 Luna, C = Mercury 3).

Exact task text (appended to the shared preamble in the Method section):

treeward accepts whatever string is in a `.treeward` file's `sha256` field. Hand-edit one to `sha256 = "abc"` (or an
empty string, or something with an escape character in it) and every command loads it happily: `status` reports the
tree clean as long as the file's mtime and size still match, `update` keeps carrying the value forward, and with
`--verify` the garbage goes into comparisons, the fingerprint, and the diff display. We already fixed the display
crash this used to cause, but the underlying problem is that a value treeward could never have written is being
trusted.

Our policy is that a corrupted ward file is a fatal error, so please treat a malformed checksum that way. treeward
always writes sha256 as exactly 64 lowercase hex characters, and anything else in a loaded ward file (wrong length,
non-hex characters, non-ASCII, and also uppercase hex, since we never write that) should make every command that loads
the file (`status` in all its modes, `verify`, `init`/`update`) fail with a fatal error (exit 255) before the value is
used for anything. The error should say which entry has the bad checksum. A well-formed lowercase checksum that simply
doesn't match the file's contents is not corruption and should keep behaving exactly as it does today.

Reference PR: status --diff (#82). Snapshot at parent 9b21ea8.

Defects found by the reviewing agent:

• Mercury 3
  • minor Checksum shortening slices by byte index and panics on non-ASCII sha256 from a corrupt ward file
  • minor `collect_new_state = purpose != Display` also fires for WardUpdate, so `update` now clones prev_entry for every compared entry and the ward entry for every removed one
  • minor Silent-corruption integration test does not test silent corruption
• GPT-6 Luna
  • minor Size rounding can print `1024 KB` instead of `1.0 MB`
• Claude Haiku 5.5
  • major Status code is right-aligned instead of left-aligned, contradicting the explicit `A new.txt` / `. file.txt` examples
  • minor Help-text example under DIFF DETAILS does not match real output (unpadded codes, 6-space indent vs 4)
  • minor Size rounding can print `1000.0 KB`

Reviewing agent's one-line note per run (its opinion, not a measurement):

Mercury 3

Complete and correct, with the most thorough user-facing docs, held back by a byte-slicing panic, a Removed field named `ward_entry` that the `ward_entry()` accessor deliberately ignores, a mislabelled test, and small summary inaccuracies.

GPT-6 Luna

Functionally the cleanest: no real bugs, char-safe truncation, exact tests including a fingerprint round trip. It loses points for deleting a large amount of valuable existing documentation in status.rs and an existing README example.

Claude Haiku 5.5

The diff engine is correct and cleanly built (a one-line format fix passes all 14 hidden tests), but it right-aligns the status column against an explicit example, which breaks the 'status lines are not indented' contract, and it adds no CLI tests.

Full unblinded review: reviews/c10-status-diff.md (candidate letters: A = Claude Haiku 5.5, B = Mercury 3, C = GPT-6 Luna).

Exact task text (appended to the shared preamble in the Method section):

Please add a `--diff` flag to `treeward status`. Today `status` tells me *that* something changed (`M`, `R`, ...) but
not *what* changed, so before accepting a changeset I end up digging through `.treeward` files by hand. With `--diff`,
each changed entry should be followed by indented detail lines saying what changed.

What I want to see:

- Modified file: one line per field that actually changed, out of size, mtime, and sha256, showing old and new values.
  Fields that did not change are not shown.
- Symlink whose target changed: a `target: OLD -> NEW` line, e.g. `target: target1.txt -> target2.txt`.
- Type change (say a file replaced by a symlink): what it was and what it is now, as a `was: ...` line and a `now: ...`
  line, e.g. `was: file (12 bytes, sha256: ...)` and `now: symlink -> somewhere`.
- Removed entry: a `was: ...` line describing what the ward had recorded: `was: file (<size>, sha256: <checksum>)`,
  `was: directory`, or `was: symlink -> <target>`.
- Added entries and (with `--all`) unchanged entries get no detail lines.

Roughly like this:

```text
M  data.json
   size: 1.2 KB -> 1.5 KB
   mtime: 2024-01-15 10:30:45.123 -> 2024-01-16 14:22:10.456
   sha256: abc123def456... -> 789xyz012345...
R  oldfile.txt
   was: file (256 bytes, sha256: abc123def456...)
```

The labels (`size:`, `mtime:`, `sha256:`, `target:`, `was:`, `now:`) and the `->` arrows are what scripts and my eyes
will key on, so keep them as shown. Detail lines are indented; status lines are not. How you format sizes,
timestamps, and checksums is up to you, as long as it is readable (human-readable sizes, a readable local timestamp,
and a shortened checksum are what I have in mind). Pulling in a crate for time formatting is fine.

Behavior:

- `--diff` implies `--verify`: files with changed metadata get checksummed, so a real content change shows as `M` (not
  `M?`) and the sha256 line can be shown. The fingerprint it prints must be the same one `status --verify` would print,
  so it works with `update --verify --fingerprint ...`.
- `--diff --always-verify` checksums everything, and the diff includes any checksum changes found that way.
- `--diff --all` lists unchanged entries too, without details. With no changes, `status --diff` (with or without
  `--all`) behaves like plain `status`: exit 0 and no fingerprint.
- Exit codes and stderr behavior stay as they are today (1 when there are changes, nothing on stderr for a normal
  unclean result).
- `verify` output does not change apart from the alignment below.

While you're in there: pad the status code to a two-character column in the listing (for both `status` and `verify`),
so paths line up whether the code is `M?` or `A`: `A  new.txt`, `M? data.json`, `.  file.txt`.