docs: follow the storage move from nuc/USB to nas/SATA

backup-strategy (the entry point) still described nuc pulling the ks4
replicas: the leg, its WireGuard peer and the target pool now live on
nas with the 4 TB on direct SATA. Also: ks4 README flow chart redrawn
for the new topology, incus-copy leg 2 retargeted, usb4t-dropouts
marked RESOLVED (kept for the diagnosis method and the alerting gap),
and ks2/plan records that the interim push was deliberately not
re-enabled.

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

ks4/incus-copy.md

@@ -8,7 +8,7 @@ push to `ks2` (decommissioning):
 
 1. **local** — replicas + dumps on a dedicated `backup` zpool on ks4's
    second disk (`sdb5`), survives `sda` death
-2. **off-site** — replicas pulled by **nuc** into pool `ks4backup`
+2. **off-site** — replicas pulled by **nas** into pool `ks4backup`
    (dataset `usb4t/backup/ks4`), survives losing ks4 entirely
 
 ## The script
@@ -74,7 +74,7 @@ Cron (root on ks4) — replaces both ks2 jobs:
 ⚠️ Replicas in the `backup` project must stay **stopped** — they keep
 the live containers' static `192.168.1.x` addresses.
 
-## Leg 2 — off-site pull from nuc
+## Leg 2 — off-site pull from nas (was nuc until 2026-08-30)
 
 Storage pool on nuc (done 2026-08-09): `ks4backup`, backed by the
 dataset `usb4t/backup/ks4` on the USB 4 TB pool (quota on `usb4t/backup`
@@ -87,7 +87,7 @@ incus storage create ks4backup zfs source=usb4t/backup/ks4
 Replicas live only on the USB drive — if it fails, only backups are
 lost; nuc's own instances (pool `data` on the SSD) are unaffected.
 
-**Direction: nuc pulls, through the WireGuard tunnel.** Verified
+**Direction: nas pulls, through the WireGuard tunnel.** Verified
 2026-08-09: ks4's API listens on wildcard `:8443` (so it answers on
 `192.168.1.1`, the `incusbr0` host address) but is **firewalled from
 the internet** — the VPN path keeps it that way, needs no inbound port