VSB-TUO/fix(ci): put PasswordAuthentication first in auth chain (#1326)

The customer-vsb-tuo-test backend image lists LDAPAuthentication first,
with authentication-ldap provider_url ldaps://ldap.vsb.cz:636/, which is
unreachable from CI runners (TCP connect blackholes; DSpace sets no JNDI
connect timeout). Every admin login therefore hangs on the LDAP connect
(~21s locally, up to ~127s on CI) before falling through to password,
which breaks every login-gated dspace-angular e2e (integration) test.

Reordering so PasswordAuthentication is tried first makes the demo/e2e
admin login instant (~0.4s, verified locally against the 29.1.2024 demo
dump); real LDAP users still fall through to LDAPAuthentication unchanged.
This matches the working customer/uk configuration.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

Author: milanmajchrak

dspace/config/modules/authentication.cfg

@@ -60,7 +60,10 @@
 
 # Authentication by Password (encrypted in DSpace's database). See authentication-password.cfg for default configuration.
 # Enabled by default (to disable, either comment out, or define a new list of AuthenticationMethod plugins in your local.cfg)
-plugin.sequence.org.dspace.authenticate.AuthenticationMethod = org.dspace.authenticate.LDAPAuthentication,org.dspace.authenticate.PasswordAuthentication
+# PasswordAuthentication is FIRST so local-password accounts (incl. the e2e/demo
+# admin) log in without first blocking on the LDAP server, which is unreachable
+# from CI runners. Real LDAP users still fall through to LDAPAuthentication.
+plugin.sequence.org.dspace.authenticate.AuthenticationMethod = org.dspace.authenticate.PasswordAuthentication, org.dspace.authenticate.LDAPAuthentication
 
 
 #---------------------------------------------------------------#