wger: its app login API gets its JWT key pair (R-737)

The template set no JWT_PRIVATE_KEY/JWT_PUBLIC_KEY, so the app login (the mobile app's route) answered 500
on a CORRECT password. The deploy's generators cannot make an RSA pair, so the start command makes it ONCE
with wger's own `manage.py generate-jwt-keys`, keeps it 0600 on wger's data volume (a restore brings it
back), and loads it before the image's own entrypoint. Measured on the bench (2.7): right password 200 with
an access token that reads the API (200); wrong password 400 (allauth's answer); the key survives a
restart. No image moves.

Evidence: felhom.eu/documentation/audits/night-rulings-2026-09-30/D/

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

templates/wger/docker-compose.yml

@@ -11,6 +11,21 @@ services:
   wger:
     image: wger/server:2.7
     container_name: wger
+    # R-737 (2026-09-30): wger's app login API (the mobile app's) signs JWTs with JWT_PRIVATE_KEY / JWT_PUBLIC_KEY — an
+    # RSA pair the deploy's generators cannot make, and without it a CORRECT password answered 500. So the pair is made
+    # ONCE by wger's own `manage.py generate-jwt-keys`, kept 0600 on wger's own data volume (a restore brings the same
+    # key back), and loaded before the image's own entrypoint. Never printed.
+    entrypoint:
+      - /bin/sh
+      - -c
+      - |
+        K=/home/wger/db/.felhom-jwt.env
+        if [ ! -s "$$K" ]; then
+          (cd /home/wger/src && python3 manage.py generate-jwt-keys 2>/dev/null) | grep -E '^JWT_(PRIVATE|PUBLIC)_KEY=' > "$$K.tmp"
+          if [ "$$(grep -c . "$$K.tmp")" = 2 ]; then mv "$$K.tmp" "$$K" && chmod 600 "$$K"; else rm -f "$$K.tmp"; echo "felhom: JWT keys could not be made" >&2; fi
+        fi
+        if [ -s "$$K" ]; then set -a; . "$$K"; set +a; fi
+        exec /home/wger/entrypoint.sh
     restart: unless-stopped
     environment:
       - TZ=Europe/Budapest