docs: stop overstating the risk of interrupting a sync

The README claimed that interrupting left buffers unwritten and therefore
corruption. That is wrong. The kernel flushes dirty pages within
dirty_expire_centisecs, thirty seconds by default, and umount syncs before it
returns, so losing data requires interrupting and pulling the card inside that
window and skipping the unmount.

The trap is still worth having, for a smaller and more honest reason: it
removes a manual step and makes the exit deterministic, so the same "safe to
disconnect" appears whichever way the run ends. What actually loses data is
pulling the card without unmounting at all, which has nothing to do with
whether the transfer was interrupted.

README.md

@@ -197,14 +197,20 @@ After an unclean kill or a power cut a hidden `.track.mp3.XXXXXX` can survive.
 It is not playable, it is not in the source, and the next run's `--delete`
 removes it.
 
-The real risk is not rsync's, it is the filesystem's: FAT32 has no journal, so
-buffers that never reach the card are corruption. The script therefore traps
-`INT` and `TERM` and still flushes and unmounts on the way out, exiting 130.
-Both the normal path and the interrupt path call the same function, so they
-cannot drift apart.
+Interrupting does not, by itself, endanger the filesystem. The kernel flushes
+dirty pages within `dirty_expire_centisecs` — thirty seconds by default — and
+`umount` always syncs before it returns. Losing data needs you to interrupt,
+*and* pull the card inside that window, *and* skip the unmount.
 
-The one case nothing can help with is pulling the cable or the card mid-write.
-Wait for the unmount.
+The script still traps `INT` and `TERM` and flushes and unmounts on the way
+out, exiting 130. Not because a Ctrl-C is dangerous, but because it removes the
+manual step and makes the exit deterministic — you get the same "safe to
+disconnect" either way, rather than having to remember which path you took.
+Both paths call the same function, so they cannot drift apart.
+
+What genuinely does lose data is pulling the cable or the card without
+unmounting at all, interrupted or not. FAT32 has no journal. Wait for the
+unmount line.
 
 ### Making it faster over a network mount