Warn when the webroot holds an image-initialised instance, not a restore

Running this play against an empty ~/podman-data/nextcloud does not fail. It
creates the webroot, writes the environment file, starts the image, and the
entrypoint initialises a fresh, uninstalled instance there -- its own code
rsynced in, data/.ocdata created, and no config.php, because there is no
NEXTCLOUD_ADMIN_USER to install with.

Copying monoco's tree on top of that then merges two versions of the code, which
is the drift the rest of this role warns about, and nothing in the play's output
says so. The role now stats config/config.php before the container starts and
warns when it is missing, naming both cases: a copy that never landed, and a play
that ran before the copy.

It warns rather than fails because installing a new instance through the web UI is
a legitimate use of this playbook and has no config.php until the installer
finishes. readme.md gains the recovery step next to the deploy step, including
why the rm -rf needs no `podman unshare`.

nextcloud/readme.md

@@ -450,6 +450,29 @@ rsync -aP --rsync-path='sudo rsync' monoco:/var/lib/nextcloud/ ~/nextcloud-copy/
 rsync -aP ~/nextcloud-copy/ emily:~/podman-data/nextcloud/
 ```
 
+### If you ran the playbook before copying
+
+Running this play against an empty `~/podman-data/nextcloud` does not fail — it
+creates the webroot, writes the environment file, starts the image, and the
+entrypoint initialises a **fresh, uninstalled** instance there: the image's own
+code rsynced in, `data/.ocdata` created, and no `config.php`, because there is no
+`NEXTCLOUD_ADMIN_USER` to install with.
+
+That is not a usable instance, and worse, copying monoco's tree on top of it
+**merges two versions of the code** — the drift this page spends the rest of its
+time warning about, produced silently by a play that reported success. The role
+now warns when it finds a webroot with no `config/config.php`, but the recovery is
+to start from a clean webroot:
+
+```bash
+ssh emily 'systemctl --user stop nextcloud.service
+           rm -rf ~/podman-data/nextcloud'
+```
+
+`rm -rf` needs no `podman unshare`: the role creates the webroot as the connection
+user, and under `keep-id:uid=33` everything the container writes lands on that same
+user. Then take the copy in step 3 and come back to step 4.
+
 ### 4. Deploy
 
 ```bash

nextcloud/roles/nextcloud/tasks/main.yaml

@@ -13,6 +13,36 @@
     group: "{{ podman_user }}"
     mode: '0755'
 
+# A migration target should already hold config/config.php, because the webroot is
+# copied from monoco before this play runs (readme.md, "Migrating the data from
+# monoco"). Two situations leave it missing, and both are worth saying out loud
+# before the container starts rather than discovering afterwards:
+#
+#   - the copy never landed, so the image initialises a fresh instance and the
+#     site comes up empty;
+#   - this play was run *before* the copy, so the image's own rsynced code is now
+#     in the webroot. Copying monoco's tree on top of that merges two versions of
+#     the code — the drift the rest of this role warns about — and the play
+#     reports success either way.
+#
+# It warns rather than fails because installing a new instance through the web UI
+# is a legitimate use, and that instance has no config.php until the installer
+# finishes.
+- name: Check whether the webroot already holds an instance
+  ansible.builtin.stat:
+    path: "{{ host_directory }}/config/config.php"
+  register: nextcloud_config
+
+- name: Warn if the webroot has no config.php
+  ansible.builtin.debug:
+    msg: >-
+      {{ host_directory }}/config/config.php does not exist, so this webroot is
+      not a restored Nextcloud instance. Migrating? Stop the unit, delete
+      {{ host_directory }}, copy /var/lib/nextcloud from monoco first, and run
+      this play again — see readme.md, "If you ran the playbook before copying".
+      Installing a new instance through the web UI? Ignore this.
+  when: not nextcloud_config.stat.exists
+
 # The entrypoint takes an flock on this path using a root-owned shell redirect
 # (`) 9> /var/www/html/nextcloud-init-sync.lock`, in the nextcloud/docker
 # entrypoint). Creating it here means it belongs to {{ podman_user }} and stays