Say what a missing webroot looks like, and stop pointing at a removed failure

The failure that prompted this is the environment file being absent:

    Error: parsing file ".../nextcloud.env": ... no such file or directory
    nextcloud.service: Main process exited, code=exited, status=125/n/a

The play creates that file before it installs or starts anything, so this cannot
come from a play run: it is a start outside one, after ~/podman-data/nextcloud was
removed. The unit is WantedBy=default.target, so it retries at boot and fails the
same way until the play is run again. The readme now says so, because the fix is
not obvious from a 125.

The rescue message was also stale: it sent readers to look for "Permission denied"
under /usr/local/etc/php/conf.d, which was the PHP session file this playbook no
longer creates or mounts, and it had lost the reset-failed hint when the message
was shortened. It now names the failure that actually happens (a removed webroot),
keeps the database/cache/image pointers that are still real, and gives the command
for a unit left failed by an earlier attempt.

nextcloud/readme.md

@@ -262,6 +262,12 @@ systemctl --user reset-failed nextcloud.service
 
 ## Notes and gotchas
 
+- **The environment file is state, and it lives inside the webroot.** So is the
+  code, `config.php` and `data/`. Removing `~/podman-data/nextcloud` therefore
+  leaves a unit that cannot start — `parsing file .../nextcloud.env: no such file
+  or directory`, exit status 125 — and because the generated unit is
+  `WantedBy=default.target` it will also fail that way at boot. Re-run the playbook:
+  it recreates the directory, the environment file and the container.
 - **`activating` is not a healthy state.** A crash-looping container spends its
   time `activating` between restarts, so the play waits on `status.php` rather than
   on `is-active`, and reports the journal on failure.

nextcloud/roles/nextcloud/tasks/main.yaml

@@ -89,9 +89,13 @@
     - name: Fail
       ansible.builtin.fail:
         msg: >-
-          Nextcloud is not serving — see the diagnostics above. A "Permission
-          denied" under /usr/local/etc/php/conf.d, anything about `db` or `redis`,
-          and "downgrading is not supported" each point somewhere different.
+          Nextcloud is not serving — the reason is in the diagnostics above.
+          `no such file or directory` for nextcloud.env or a path under
+          /var/www/html means this host's webroot was removed without re-running
+          this play, and anything about `db`, `redis` or "downgrading is not
+          supported" points at the database, the cache or the image instead. If
+          the unit is in the `failed` state from an earlier attempt:
+          systemctl --user reset-failed {{ unit_name }}
 
 # Nextcloud wants `cron.php` every five minutes. This has to be *this user's*
 # crontab, not root's: root cannot `podman exec` into another user's rootless