plakar-incus-integration: chain the S3 instance leg after incus-copy

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

ks4/plakar-incus-integration.md

@@ -127,7 +127,14 @@ major upgrade; a mismatch surfaces at backup time, so run a manual
 - xattrs / ACLs / device nodes over sftp — coverage and fidelity.
 - VMs: file access needs a running incus-agent — out of scope for ks4
   (containers only); document the limitation.
-- Scheduling/locking: chain after the 01:00 incus-copy (flock on the
-  same lock, or a wrapper script).
+- ~~Scheduling/locking~~ decided 2026-08-23: the S3 instance leg is
+  only as fresh as the last **completed** local incus-copy, so both
+  run chained in one cron entry —
+  `incus-copy.sh -p backup -s backup ; <plakar incus leg>` — never at
+  a fixed offset (a long refresh, e.g. a post-gap full re-send, would
+  race it). `;` not `&&`: a partially failed copy leaves stale but
+  internally consistent replicas, still worth uploading. Same rule
+  for manual test runs: check `/var/log/incus-copy.log` completed
+  first.
 - S3 hardening: scoped credentials (no delete), versioning/object
   lock, plakar client-side encryption passphrase storage.