Decouple SGU authentication from profile pages

README.md

@@ -12,13 +12,14 @@ Directory synchronization, deployment scripts, and tests.
 
 1. The Windows tile collects a `DO`, `AL`, or `AD` institutional key and a password.
 2. It sends that exact password over mutually authenticated TLS to the broker.
-3. The broker validates the same key/password pair against the configured SGU
-   NTLM endpoint. The same logical authenticated request reads the minimum
-   available SGU profile fields.
-4. On success, the broker creates or moves the AD user, updates the available
+3. The broker validates the same key/password pair against the lightweight SGU
+   NTLM root. Only an authoritative `401`/`403` rejects the credential.
+4. After successful authentication, the broker makes a separately bounded,
+   best-effort request for the minimum available SGU profile fields.
+5. On success, the broker creates or moves the AD user, updates the available
    name/mail/title/department/address metadata when available, and sets the AD password
    to the exact submitted password.
-5. The Credential Provider serializes the original `SecureString` to Windows.
+6. The Credential Provider serializes the original `SecureString` to Windows.
 
 No derived password is created. Passwords are not written to a database, file,
 event log, application log, command line, or response.
@@ -32,7 +33,8 @@ name, email, career, and postal address. The career becomes an AD title in the
 form `Estudiante de ...`; faculty/department remains unset because the verified
 page does not expose it. Professors retain the menu display-name fallback until
 a richer role-specific page is verified. Missing or changed presentation HTML
-never blocks authentication or password synchronization.
+never blocks authentication or password synchronization after the lightweight
+NTLM root has accepted the credential.
 
 Operational documentation: