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/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