Cut the Nextcloud role back to what it actually needs

The role had grown machinery that the problem does not require. Removed:

- The init-sync lock pre-create. It guarded against one file in the webroot being
  owned by a subuid, which is cosmetic: the file is 0644, so it is readable and
  removable by host-side tools either way.
- The image ID read/pull pair. No other service playbook pulls an image, and the
  update path is two commands the readme now spells out.
- redis-session.ini.j2 and its three variables. The mount is load-bearing -- the
  entrypoint cannot write into the image's conf.d and dies trying -- but the
  template is not: the entrypoint writes that file itself on every start. One
  touched empty file and one Volume line replace the template and the variables.
- The config.php stat, the wizard note, the maintenance-mode wait, the occ status
  report, the getent checks, the timer report. The installed/not-installed
  branching existed only because the readiness gates were written for an installed
  instance; with a gate that fits both, none of the branching is needed.
- Comments that narrated this play's earlier runs rather than the system.

What is left is four tasks before the start, a start-plus-gate block whose rescue
collects the journal, and four tasks for the background-job timer: 149 lines and
about 130 of them code, against 313 before. The readme loses its migration-era
bulk for the same reason and is 297 lines, in line with the other services'.

The one gate is now Nextcloud's own status.php inside the container. It answers
only once the entrypoint has finished -- including any `occ upgrade`, which runs
before Apache starts, so an update in progress is waited out rather than missed --
it reports `installed` either way, so a fresh webroot and an installed instance go
through the same check, and it carries `maintenance` as well, which is the one
state a probe would otherwise call healthy while every page returned 503.

nextcloud/roles/postgres/tasks/main.yaml

@@ -1,41 +1,21 @@
 ---
-# Attach this app's network to the shared Postgres unit.
-#
-# Postgres knows nothing about its clients, exactly like Caddy: a service joins
-# by dropping 50-nextcloud.conf and the shared 10-network-aliases.conf next to
-# postgres.container. The canonical way to do that is the shared include below —
-# it writes the same bytes every service writes, asserts that nextcloud.network
-# already exists, and notifies the "Restart Postgres" handler defined in this
-# role.
-#
-# This runs in the roles phase, which is after the register include in
-# playbook.yml's pre_tasks has created nextcloud.network.
+# Attach this app's network to the shared Postgres unit, and make sure the
+# database exists.
 
 - name: Attach Nextcloud to Postgres
   ansible.builtin.include_tasks: "{{ playbook_dir }}/../postgres/roles/attach/tasks/main.yaml"
 
-# On a first attach both drop-ins are new, so Postgres has to be recreated to
-# join nextcloud_net — and that restart is a *handler*, which by default runs at
-# the end of the play, after the nextcloud role has already started the app. The
-# app would then come up before `db` resolves, fail its own readiness check, and
-# fail the play on a machine where nothing is actually wrong.
-#
-# Flushing applies the new drop-in before the app starts. It also flushes the
-# "Restart Caddy" that the register pre_task queued, which is what attaches Caddy
-# to nextcloud_net — also wanted before the app is expected to serve. On later
-# runs nothing is pending and this is a no-op.
-- name: Apply the Postgres network change before starting Nextcloud
+# The restart that joins Postgres to nextcloud_net is a handler, so by default it
+# would run at the end of the play — after the app has started and failed to
+# resolve `db`. Flushing first also applies the Caddy restart queued by the
+# register pre_task. Nothing is pending on later runs.
+- name: Apply the network change before starting Nextcloud
   ansible.builtin.meta: flush_handlers
 
-# The database itself. Postgres is a shared unit that ships one default database,
-# and nothing else in this repo knows what this app's database is called — so
-# without this, a first run on a fresh host reaches the setup wizard (or the
-# unattended install) only to fail on "database {{ pg_database }} does not exist".
-# Later runs find it and do nothing.
-#
-# psql runs inside the Postgres container rather than over the app network, so the
-# only thing this needs is a cluster that answers. The retry loop is there because
-# the flush above may have just restarted it.
+# Postgres ships one default database and only this app knows the name of its own,
+# so on a fresh cluster the installer would otherwise fail with "database
+# nextcloud does not exist". The retry is for the restart the flush above may have
+# just done.
 - name: Check whether the {{ pg_database }} database exists
   ansible.builtin.command: >-
     podman exec -e PGPASSWORD={{ pg_password }} {{ postgres_container }}
@@ -52,10 +32,9 @@
   ansible.builtin.assert:
     that: nextcloud_db.rc == 0
     fail_msg: >-
-      The shared Postgres container ({{ postgres_container }}) did not answer.
-      Run postgres/playbook.yml on this host first: this playbook attaches to that
-      cluster and creates its own database in it. Postgres said:
-      {{ nextcloud_db.stderr | default('') | trim }}
+      {{ postgres_container }} did not answer. Run postgres/playbook.yml on this
+      host first — this play attaches to that cluster and creates its own database
+      in it.
 
 - name: Create the {{ pg_database }} database
   ansible.builtin.command: >-