fix(runtime): avoid Copy to RAM worker panic

bible-local/decisions/2026-09-03-runtime-copy-to-ram-loop-change-fd.md

@@ -24,6 +24,12 @@ The Linux ABI defines `LOOP_CHANGE_FD` as `0x4C06` and
 `ioctlLoopChangeFD`, so every fallback reassociation called the wrong ioctl
 and received `EINVAL`.
 
+The follow-up live run exposed another independent failure: copying the
+remaining medium tree passes a nil progress callback to `copyFileLarge`, but
+the copier called that callback unconditionally after each progress interval.
+The worker therefore panicked immediately after logging "Copying remaining
+medium files...", and the parent task only reported `exit status 1`.
+
 ## Decision
 
 - Use the correct `LOOP_CHANGE_FD` request number, `0x4C06`, and protect it
@@ -40,6 +46,8 @@ and received `EINVAL`.
 - Eject the original device without unmounting the new RAM bind mount.
 - Preserve a complete RAM copy after any failure that occurs after loop
   reassociation begins, so retry never deletes a file backing a live loop.
+- Progress reporting is optional; bulk copies without a logger must never
+  panic.
 
 ## Consequences