perf(media): the apply fsyncs the journal once per batch, not per move

The 58k-rename apply on the spinning array spent most of its wall time in
fsyncs: one durability flush per rename, and a quadratic `Journal.already()`
scan over a growing record list on top of it. Both are the journal's, not the
renames'.

- `Journal` indexes move intents by (src, dst) so `already()` is O(1).
- `--batch N` (default 64) writes N intents, fsyncs once, then performs those
  N renames. The invariant is unchanged: no rename runs before its own intent
  is durable, so a crash mid-batch replays the batch and resumes.
- Tests: a mid-batch kill loses nothing and the rerun completes; batching
  changes no final path and no journal line.

serverAppConfigs-docs/Dankserver/Media Relayout.md

@@ -81,6 +81,13 @@ An apply also leaves the release folders it emptied standing where they were —
 hundreds of them at the library root — which is what `sweep` removes, dry-run
 first, from the same journal.
 
+`--batch N` (default 64) makes the journal durable per batch instead of per
+move: N intents are written and fsynced, then those N rename. The rule a crash
+relies on — no rename runs before its intent is on disk — is unchanged, so an
+interrupted apply still replays the batch and resumes with nothing lost. Batch 1
+is the old behaviour; the only reason to name it is debugging, because on the
+spinning array it spends most of a large apply's wall time in fsyncs.
+
 After it lands, both servers need a scan or the change is invisible. [[Plex]] and
 [[Jellyfin]] own the exact requests; two laws hold at this step: `204` is
 acceptance and anything else queued nothing — re-issue the identical request