ok - login verifies outside SQL ok - login performs conditional lazy migration ok - failed login cannot reuse an authenticated session ok - non-authenticating requests preserve an existing session ok - missing and ambiguous users run dummy password verification ok - password zero is not rejected by login empty semantics ok - password change hashes before storage ok - operator form uses an empty password input ok - portal password has separate browser length constraints ok - common create and update paths hash portal passwords ok - common create and update paths redact password logs ok - all sensitive password writes disable verbose PEAR DB errors ok - empty edit preserves the existing portal credential ok - CSV portal login is independent from cleartext RADIUS setting ok - CSV retry preserves the portal-login yes/no selection ok - RADIUS cleartext setting explains the portal-password boundary ok - mng-new rejects missing credentials before writes ok - mng-new-quick rejects missing credentials before writes ok - mng-batch-add rejects missing credentials before writes ok - bill-pos-new rejects missing credentials before writes ok - mng-edit rejects missing credentials before writes ok - bill-pos-edit rejects missing credentials before writes ok - self-service validates NUL before trimming password fields ok - self-service distinguishes database and concurrent failures ok - portal password tooltip uses the English fallback dictionary ok - migration CLI handles connection, fetch, and bytewise-guard failures ok - migration uses distinct connection and silent startup-query handlers ok - fresh schema reserves 255 characters for password hashes ok - ordinary password fields retain the configured database bounds ok - portal password renderer accepts zero and omits the RADIUS maximum ok - menu password renderer applies the same portal override ok - redacted SQL keeps non-sensitive fields without exposing the hash ok - only the password-bearing write suppresses verbose DB errors ok - password-bearing writes log only redacted SQL after a real query ok - ordinary userinfo writes retain the application DB error mode ok - missing users do not produce a synthetic password update log ok - a returned PEAR DB error cannot compare as a successful write ALL PASSED