case 4711 - JWT signing key generated by the server; AYANOVA_JWT_SECRET removed

The LAN/IIS and Linux templates shipped a placeholder secret printed in the
manual, and installs that kept it signed logins with a public key; any setting
also invited short or reused values (security review F1). The setting is now
ignored (one warning at boot if still present): the server generates a key once
(48 random bytes) into jwt-signing.key in the data folder (beside the app if
there is none; owner-only on Linux) and reuses it, so sign-ins also survive a
restart where the server used to make a new key each boot (standalone, Linux
desktop). If the file cannot be used, a temporary key is used for that run.

Templates and dev launch configs drop the setting; manual updated (key page
rewritten, setting steps removed from install pages); changelog line.

Checked locally: token forged with the old placeholder 401; key file created
and reused after restart (old token 200); auth and 2FA tests pass.

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

dist/assets/lan-install-config.json

@@ -4,8 +4,7 @@
     "AYANOVA_DEFAULT_TRANSLATION":"en",
     "AYANOVA_DATA_PATH":"%ProgramData%\\ayanova",
     "AYANOVA_BACKUP_PG_DUMP_PATH": "C:\\Program Files\\PostgreSQL\\18\\bin",
-    "AYANOVA_LOG_LEVEL": "Info",
-    "AYANOVA_JWT_SECRET": "11111YourRandom32CharacterSecret"
+    "AYANOVA_LOG_LEVEL": "Info"
 }
 
 

dist/assets/linux-server/config.json

@@ -3,6 +3,5 @@
     "AYANOVA_DB_CONNECTION":"Server=localhost;Username=postgres;Password=YOUR_PASSWORD_HERE;Database=AyaNova;CommandTimeout=300;",
     "AYANOVA_DEFAULT_TRANSLATION":"en",
     "AYANOVA_DATA_PATH":"/var/ayanova/data/",
-    "AYANOVA_LOG_LEVEL": "Info",
-    "AYANOVA_JWT_SECRET": "12345YourRandom32CharacterSecret"
+    "AYANOVA_LOG_LEVEL": "Info"
 }