fix: seed app.ini into writable config volume for Gitea 1.24+

Gitea 1.24+ persists settings back to app.ini on boot (e.g. WORK_PATH).
Mounting app.ini directly as a read-only swarm config makes that write
fail (logged error, possible repo-access bugs). Mount the rendered config
as app.ini.init and seed a writable copy in the config volume instead.

docker-setup.sh.tmpl

@@ -14,15 +14,9 @@ mkdir -p ${GITEA_CUSTOM} && chmod 0500 ${GITEA_CUSTOM}
 mkdir -p ${GITEA_TEMP} && chmod 0700 ${GITEA_TEMP}
 if [ ! -w ${GITEA_TEMP} ]; then echo "${GITEA_TEMP} is not writable"; exit 1; fi
 
-# Seed app.ini into the WRITABLE config volume (/etc/gitea) from the read-only swarm config
-# (mounted at /etc/gitea/app.ini.init). Gitea must be able to PERSIST settings to app.ini — e.g.
-# Gitea 1.24+ (re)generates and SAVES the [oauth2] JWT_SECRET at LoadCommonSettings; with app.ini
-# mounted directly as a read-only swarm config this fails fatally ("open /etc/gitea/app.ini:
-# read-only file system") on (re)deploy. Seed when MISSING OR EMPTY (`! -s`, not `! -f`): upgrading
-# from a release that mounted app.ini directly as a swarm config leaves a 0-byte placeholder at
-# /etc/gitea/app.ini in the reattached config volume — `! -f` would treat that as "present" and skip,
-# leaving Gitea to boot the install wizard on an empty config. A non-empty app.ini (Gitea's persisted
-# state) is preserved across restarts; truncate/delete it to force a re-seed from the rendered config.
+# Gitea 1.24+ writes settings back to app.ini on boot (e.g. WORK_PATH), which fails when app.ini is
+# mounted directly as a read-only swarm config. So mount the rendered config as app.ini.init and seed
+# a writable copy. Use `! -s` (empty), not `! -f`: old direct-mount upgrades leave a 0-byte app.ini.
 if [ ! -s /etc/gitea/app.ini ]; then
   cp /etc/gitea/app.ini.init /etc/gitea/app.ini
 fi