feat(debyltech-cloud): add cloud.debyltech.com Nextcloud

A de Byl Technologies LLC Nextcloud cloned from the Skudak instance:
LibreSign signing for people without an account, registration off
(admin-created accounts only), no Group Folders. DNS is a terraform-managed
ALIAS to fulfillr.debyltech.com.

- containers/debyltech/cloud.yml: nextcloud/mariadb/redis on port 8091.
  It installs unattended on the first deploy, sends mail through SES as
  noreply@debyltech.com, and re-asserts the Skudak LibreSign settings.
- files/debyltechmail: skudakmail rebranded, with a new black-and-white
  wordmark and white web-UI logos.
- LibreSign is pinned to 14.2.2 from the GitHub release (sha256-checked)
  rather than `occ app:install`. The app store served a same-day 14.2.3
  whose tarball has no binary-signature metadata. 14.2.x also doesn't
  create its own download dirs, so they're pre-created.
- The backup runs nightly at 04:15 to TrueNAS /mnt/glacier/debyltechcloud and
  reaches personal iDrive via the "iDrive E2 Backup" task; the TrueNAS side
  excludes /debyltechcloud/_backup/config/**.
- Fix the libresign:configure:check gate in both instances: '\berror\b'
  becomes a backspace in Jinja and never matched, so a check reporting three
  errors passed clean. Now '\\berror\\b'.
- vault: cloud_debyltech_* secrets.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

ansible/roles/podman/templates/nextcloud/redis-debyltech.conf.j2

@@ -0,0 +1,40 @@
+# {{ ansible_managed }}
+#
+# Redis for debyltech-cloud: Nextcloud distributed cache + transactional file
+# locking. Reachable only by container name on the `shared` podman network --
+# no host port is published.
+#
+# The password lives HERE rather than on the command line as
+# `redis-server --requirepass <pass>`. That is the existing house idiom (see
+# the deleted container-nosql.yml in git history), but it leaks the secret into
+# `podman inspect`, into the generated systemd unit under
+# ~/.config/systemd/user/, and into `ps` for every user on the host. A 0640
+# config file mounted read-only keeps it out of all three.
+requirepass {{ cloud_debyltech_redis_pass }}
+
+# Bind to all interfaces WITHIN the container's network namespace. The
+# container publishes no port, so this is reachable only from the `shared`
+# podman network -- not from the host and not from the LAN.
+bind 0.0.0.0
+port 6379
+protected-mode yes
+
+# NO maxmemory / eviction policy, deliberately.
+#
+# Nextcloud puts BOTH the distributed cache and the transactional file locks in
+# this instance. Cache entries are safely evictable; LOCKS ARE NOT. An
+# `allkeys-lru` policy under memory pressure can evict a lock that a live
+# request still believes it holds, which permits concurrent writers to the same
+# file -- silent corruption rather than a visible error. With no maxmemory,
+# Redis never evicts. The host has ~14 GiB free of 31 GiB and this instance
+# holds a few hundred keys, so a cap buys nothing.
+#
+# If a cap is ever genuinely needed, use `maxmemory-policy noeviction` so Redis
+# returns an error instead of silently discarding a lock.
+
+# No persistence. Locks are ephemeral and TTL-bounded, and the cache is
+# rebuildable -- there is nothing here worth surviving a restart. Persisting
+# would be actively worse: a restored RDB could reinstate locks whose owning
+# request died, blocking files until the TTL expired.
+save ""
+appendonly no