Do not create a host file for the entrypoint's PHP session config

The role created ~/podman-data/nextcloud/redis-session.ini and the unit bind-mounted
it over the image path, purely because the entrypoint cannot write there itself.
Removed: the task, the mount, and -- because it is the only thing that triggers the
write -- REDIS_HOST from the environment file. The entrypoint now skips
configure_redis_session entirely and starts.

The Redis attach stays. The valkey role still puts nextcloud_net on the cache
container with the alias `redis`, so an instance whose config.php names that host
reaches it. Writing that configuration is config.php's business, and the readme
gives the three `occ config:system:set` lines for anyone who wants it, including
that this playbook will not do it for them.

The only thing lost is PHP session storage, which falls back to the container's own
filesystem -- a redeploy logs users out. That is the trade for not shipping a file
whose sole purpose is to work around a directory the image owns as root.

The env template and the valkey role comment both say why REDIS_HOST is absent, so
that adding it back is recognisable as the regression it is.

nextcloud/vars/default.yml

@@ -58,12 +58,11 @@ pg_user: postgres
 pg_password: '123456'
 pg_database: nextcloud
 
-# Valkey, and the alias its attach role adds. REDIS_HOST is not cosmetic:
-# config.php puts `memcache.locking` on Redis, so an unresolvable `redis` breaks
-# uploads rather than merely slowing them down.
+# Valkey, which the attach role puts this app's network on with the alias
+# `redis`. Whether Nextcloud uses it is config.php's decision: the cache and
+# `memcache.locking` live there, not in this playbook. See readme.md.
 valkey_container: valkey
 valkey_unit: "{{ valkey_container }}.service"
-redis_host: redis
 
 caddy_name: caddy
 caddyfile_path: "{{ podman_data_dir }}/{{ caddy_name }}/conf/Caddyfile"