v0.12.4

Fixed

• Applying a maintenance plan is about 5× faster. Each file used to run the full checkout inspection twice: the claim check, then again when its completion was recorded. So an apply re-read every declared file about twice per file, and rewrote the whole journal, with fsync, once per file. A 154-file lineage spent about 1–3 minutes in that loop.
  • The full freshness check now runs once before the file loop and again before finalization.
  • Per file, only cheap checks run: the exclusive claim is held, the owner and the journal are unchanged, and the file still matches its planned bytes right before it's written. A drifted file aborts with the journal resumable.
  • Completed files go to an append-only progress log beside the journal (journal-<hash>.progress). Each line is fsynced before the next file is written, so a crash resumes exactly, and a torn last line is ignored. The log is removed once the lineage is recorded.
  • Files already at the target bytes are reconciled without being recorded.
  • Measured on two real apps' core lineage (154 files): about 56–99s down to 12–16s wall-clock, and about 37s down to 8s user CPU.

---

What's Changed

• Check freshness once per apply, not per file; record progress append-only (port of #230) by @jaspertey in #232
• Release 0.12.4 by @jaspertey in #233

Full Changelog: v0.12.3...v0.12.4