Phase 2: FTP, SMB and NFS storage backends

No ng_backup code changes needed: files_external's generic backend/auth adapter (the same
ExternalStorageFactory/StorageBackend already used for S3/SFTP) already covers FTP and SMB, and
NFS was never a files_external backend to begin with (PLAN.md 3.5) -- the "local" backend plus an
admin-managed OS-level mount already does the job. This commit is test coverage and documentation.

tests/integration/targets-matrix.sh now also runs the full round trip against:
- FTP (stilliard/pure-ftpd). A first attempt with delfer/alpine-ftp-server (vsftpd) failed with a
  generic "create directory operation failed": files_external's FTP backend always builds
  absolute paths, which that server's chroot rejects even via plain php ftp_mkdir() with an
  absolute path (a relative path on the same server works fine) -- not a files_external or
  ng_backup bug, just a server-specific quirk, confirmed by switching test servers.
- SMB (dperson/samba), via a small Nextcloud image built on the fly with the smbclient PECL
  extension (libsmbclient-dev + pecl install), in its own temp directory as the build context
  (never /tmp directly). The backend *lists* as available with just the smbclient CLI binary too
  (files_external's shell-wrapped fallback), but that fallback's stream cannot seek, and ng_backup
  reads blobs back by byte range while backing up -- confirmed live, it fails the very first
  (small) backup with "Seek failed in packs/...". The native extension is genuinely required here,
  not just preferred.

README: new "Storage backend experiences" entries for both findings (and a pointer from the
"no extra PHP extensions" intro line, since SMB is the one real exception), plus NFS guidance
(mount it yourself, point the local backend at the mount point).

PLAN.md: FTP/SMB marked done; SMB/NFS testing on the user's own OMV instance stays open (internal,
not something CI can cover).

Local review (Codex + CodeRabbit) found three issues, all fixed: the README's first-pass SMB claim
("CLI tool is not enough") was imprecise about *why* -- it lists fine without the extension, it
just doesn't work for ng_backup's read pattern; the cleanup trap could abort before removing the
network if an earlier docker rm failed, and didn't remove the built image/Dockerfile; and the
Docker build used all of /tmp as its context instead of a dedicated directory.

README.md

@@ -2,8 +2,10 @@
 
 Encrypted, incremental backups of Nextcloud (database, configuration and data) with restore
 from the web interface. Works without shell access: no external programs, no extra PHP
-extensions beyond sodium. Runs on Nextcloud All-in-One, regular installations and hosted
-Nextcloud.
+extensions beyond sodium for ng_backup itself. Runs on Nextcloud All-in-One, regular
+installations and hosted Nextcloud. (Choosing SMB as a storage backend is the one exception:
+see "Storage backend experiences" below — that requirement comes from files_external, not from
+ng_backup, and applies to any Nextcloud app that writes to an SMB share.)
 
 **Status: in development (phase 1). Not ready for production use.** See `PLAN.md` for the design.
 
@@ -119,6 +121,29 @@ Contributions welcome via PR — add what you ran into with your own provider.
   verified whether this also applies to a Hetzner Storage Box **main** account (only tested with a
   sub-account so far) — if you've tried a main account, please say so in a PR.
 
+- **FTP, server-dependent absolute-path handling:** files_external's FTP backend always builds
+  absolute paths (e.g. `MKD /repo`) for the configured root, never relative ones. `atmoz/sftp`-style
+  `vsftpd` test servers (chrooted) can reject that with a generic "create directory operation
+  failed", even though a plain `ftp_mkdir()` with a *relative* path on the same server succeeds;
+  `pure-ftpd` accepts the absolute form fine. If a working FTP server rejects ng_backup's writes,
+  try a different FTP server implementation before assuming the backend itself is broken.
+
+- **SMB/CIFS *lists* as available with just the `smbclient` CLI binary, but does not actually
+  work for ng_backup without the `smbclient` PECL extension too.** files_external falls back to a
+  shell-wrapped `smbclient` process when the native extension is missing, which registers the
+  backend in `occ backup:target:backends` fine, but that fallback's stream cannot seek. ng_backup
+  reads blobs back by byte range while backing up, so even the very first (small) backup fails
+  with `Seek failed in packs/...`. Install the extension (`libsmbclient-dev` + `pecl install
+  smbclient` + `docker-php-ext-enable smbclient` on Debian-based images), not just the CLI tool —
+  the backend being listed is not proof it will work here. Once the extension is present it works
+  the same as any other backend; no ng_backup-specific config beyond host/share/user/password.
+
+- **NFS is not a files_external backend at all.** Mount the NFS export on the server yourself
+  (e.g. via `/etc/fstab` or a systemd `.mount` unit) and point ng_backup's `local` backend at the
+  mount point; ng_backup never mounts or unmounts anything on its own, so an NFS mount dropping
+  mid-run behaves like any other local-path failure (the run resumes). See PLAN.md 3.5 for why NFS
+  can't be driven from PHP directly.
+
 ## Commands
 
 | Command | Purpose |