9ebcf59af9
Some checks failed
CI / Unit & Component Tests (push) Failing after 2m47s
CI / OCR Service Tests (push) Successful in 15s
CI / Compose Bucket Idempotency (push) Successful in 56s
CI / Backend Unit Tests (push) Successful in 4m17s
CI / fail2ban Regex (push) Successful in 40s
CI / Unit & Component Tests (pull_request) Failing after 2m51s
CI / OCR Service Tests (pull_request) Successful in 17s
CI / fail2ban Regex (pull_request) Has been cancelled
CI / Compose Bucket Idempotency (pull_request) Has been cancelled
CI / Backend Unit Tests (pull_request) Has been cancelled
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>