Add Nextcloud cloud storage role with split Redis caching strategy

## New Features

- **Nextcloud Role**: Complete cloud storage deployment using Podman Quadlet
  - FPM variant with Caddy reverse proxy and FastCGI
  - PostgreSQL database via Unix socket
  - Valkey/Redis for app-level caching and file locking
  - Automatic HTTPS with Let's Encrypt via Caddy
  - Dual-root pattern: Caddy serves static assets, FPM handles PHP

- **Split Caching Strategy**: Redis caching WITHOUT Redis sessions
  - Custom redis.config.php template for app-level caching only
  - File-based PHP sessions for stability (avoids session lock issues)
  - Prevents cascading failures from session lock contention
  - Documented in role README with detailed rationale

## Infrastructure Updates

- **Socket Permissions**: Update PostgreSQL and Valkey to mode 777
  - Required for containers that switch users (root → www-data)
  - Nextcloud container loses supplementary groups on user switch
  - Security maintained via password authentication (scram-sha-256, requirepass)
  - Documented socket permission architecture in docs/

- **PostgreSQL**: Export client group GID as fact for dependent roles
- **Valkey**: Export client group GID as fact, update socket fix service

## Documentation

- New: docs/socket-permissions-architecture.md
  - Explains 777 vs 770 socket permission trade-offs
  - Documents why group-based access doesn't work for user-switching containers
  - Provides TCP alternative for stricter security requirements

- Updated: All role READMEs with socket permission notes
- New: Nextcloud README with comprehensive deployment, troubleshooting, and Redis architecture documentation

## Configuration

- host_vars: Add Nextcloud vault variables and configuration
- site.yml: Include Nextcloud role in main playbook

## Technical Details

**Why disable Redis sessions?**

The official Nextcloud container enables Redis session handling via REDIS_HOST env var,
which causes severe performance issues:

1. Session lock contention under high concurrency (browser parallel asset requests)
2. Infinite lock retries (default lock_retries=-1) blocking FPM workers
3. Timeout orphaning: reverse proxy kills connection, worker keeps lock
4. Worker pool exhaustion: all 5 default workers blocked on same session lock
5. Cascading failure: new requests queue, more timeouts, more orphaned locks

Solution: Use file-based sessions (reliable, fast for single-server) while keeping
Redis for distributed cache and transactional file locking via custom config file.

This provides optimal performance without the complexity of Redis session debugging.

Tested: Fresh deployment on arch-vps (69.62.119.31)
Domain: https://cloud.jnss.me/

roles/postgresql/README.md

@@ -114,6 +114,37 @@ The role implements comprehensive systemd security restrictions:
 - Local connections only by default
 - Encrypted password storage
 
+### Unix Socket Permissions
+
+**Current Configuration**: Socket permissions are set to `0777` (world-readable/writable)
+
+**Rationale**:
+- Allows containers running as any UID to access the socket
+- Needed for containers that start as root and switch to unprivileged users (e.g., Nextcloud's www-data)
+- Security is maintained via password authentication (scram-sha-256)
+- Sockets are local-only (not network-exposed)
+
+**Security Considerations**:
+- ✅ Any local process can connect to the socket
+- ✅ But still requires valid username + password to authenticate
+- ✅ Limited to processes on same host (not network)
+- ✅ Passwords stored encrypted with scram-sha-256
+
+**Alternative Approach (TCP)**:
+If you prefer more restrictive socket permissions, you can use TCP instead:
+
+```yaml
+# In host_vars
+postgresql_listen_addresses: "127.0.0.1"  # Listen on localhost TCP
+postgresql_unix_socket_permissions: "0770"  # Restrict socket to group
+
+# In application configs
+# Use: host=127.0.0.1 port=5432
+# Instead of: host=/var/run/postgresql
+```
+
+This provides the same security level (password-authenticated, localhost-only) but uses TCP instead of Unix sockets.
+
 ### File System Security
 
 - Proper ownership and permissions

roles/postgresql/defaults/main.yml

@@ -20,7 +20,11 @@ postgresql_port: 5432
 # Unix Socket Configuration  
 postgresql_unix_socket_enabled: true
 postgresql_unix_socket_directories: "/var/run/postgresql"
-postgresql_unix_socket_permissions: "0770"
+# Note: 0777 allows containers running as any UID to access the socket
+# This is needed for containers that start as root and switch to unprivileged users (e.g., Nextcloud)
+# Security is maintained via password authentication (scram-sha-256)
+# Alternative: Use TCP on 127.0.0.1:5432 (see documentation)
+postgresql_unix_socket_permissions: "0777"
 
 # Group-Based Access Control
 postgresql_client_group: "postgres-clients"

roles/postgresql/tasks/main.yml

@@ -86,7 +86,7 @@
     state: directory
     owner: postgres
     group: "{{ postgresql_client_group }}"
-    mode: '0770'
+    mode: '0777'
   when: postgresql_unix_socket_enabled
 
 - name: Get PostgreSQL client group GID for containerized applications