fix(user): rename yaml key username→email so admin seed reads APP_ADMIN_USERNAME

Closes #513.

UserDataInitializer reads `@Value("${app.admin.email:...}")` but
application.yaml mapped APP_ADMIN_USERNAME to `app.admin.username`.
The keys never connected — env vars APP_ADMIN_USERNAME and
APP_ADMIN_PASSWORD were silently ignored and the admin user got
seeded with the hardcoded defaults admin@familyarchive.local /
admin123.

For production this is HIGH severity: DEPLOYMENT.md §3.5 documents
the admin password as permanently locked on first deploy. The
bug locked the lock-in to dev defaults, not to whatever an operator
set in PROD_APP_ADMIN_PASSWORD.

Rename yaml key from `username:` to `email:` so the Spring property
`app.admin.email` actually exists. Keep env-var name
APP_ADMIN_USERNAME (matches the already-set Gitea secrets and
DEPLOYMENT.md §3.3). Default value updated to an email-shape.

Added AdminSeedPropertyKeyTest (Binder pattern, no Spring context):
verifies both `app.admin.email` and `app.admin.password` resolve
from the yaml. Confirmed red without the fix, green with it.

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

backend/src/main/resources/application.yaml

@@ -69,7 +69,11 @@ app:
     from: ${APP_MAIL_FROM:noreply@familienarchiv.local}
 
   admin:
-    username: ${APP_ADMIN_USERNAME:admin}
+    # Key must be `email`, not `username` — UserDataInitializer reads
+    # `${app.admin.email:...}`. The env-var name stays APP_ADMIN_USERNAME
+    # to match the existing Gitea secrets and DEPLOYMENT.md §3.3.
+    # See #513.
+    email: ${APP_ADMIN_USERNAME:admin@familienarchiv.local}
     password: ${APP_ADMIN_PASSWORD:admin123}
 
   import: