`bdrive log` sorted by the lamport clock, so the wall-clock stamps it prints
came out non-monotonic — two 06:09:24 rows above a 06:10:00 row. And every op
of one scan is stamped with that scan's commit time, so a 22-file agent run
collapsed onto a single stamp. Neither is readable as a timeline, which is the
whole job of the command.
Two display-only changes:
- `journal.Op` gains `Mtime` (`omitzero`, so old journals and old binaries are
unaffected), populated on put ops from the `os.FileInfo` the scan already
holds. Deletes and conflict copies keep their commit time.
- `syncer.DisplayTime` / `SortForDisplay` order by the timestamp that is
actually printed, ties broken by reversed `journal.Less`. `bdrive log` sorts
and *then* truncates, so `-n 25` is the 25 newest by that stamp.
`journal.Less`, `Sort`, and `Replay` are untouched — replay order is the
convergence contract, so the sort lives in `syncer`, not in `journal`.
`LogEntries` also keeps returning causal order because `bdrive restore` walks
it to find a file's previous version.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
