LDAP sync: `Missing attribute: givenName` against servers that return attribute names in a different case (LLDAP) — attribute lookup should be case-insensitive (RFC 4512 §2.5)

Start at crates/defguard_core/src/enterprise/ldap/client.rs:449 and ldap/model.rs:73,344, then inspect how SearchEntry attributes are read by name. Reproduce with LLDAP 0.6.3 using POST /ldap/test or an LDAP sync. Done means returned attribute names with different casing resolve for givenName, sn, mail, uniqueMember, and other named attributes without Missing attribute errors.

Environment: Defguard Core 2.1.0 (Business/free tier), LDAP server LLDAP 0.6.3, ldap_user_obj_class=inetOrgPerson, ldap_group_obj_class=groupOfUniqueNames, ldap_member_attr=uniqueMember, LDAP authority, two-way sync.

What happens: POST /ldap/test and the sync find every user, then each one is skipped with Missing attribute: givenName.

Why (from the sources): the user search asks for ["*", ldap_member_attr] and then reads the attribute with an exact HashMap::get("givenName") — crates/defguard_core/src/enterprise/ldap/client.rs:449 and ldap/model.rs:73,344 in v2.1.0 (still exact on main when checked on 2026-09-20). LLDAP expands the * request from its own attribute table, which spells the key givenname (lower case), and that spelling wins over an explicitly requested givenName (crates/ldap/src/core/utils.rs::expand_attribute_wildcards, a BTreeMap::extend). So the entry comes back with givenname and the exact lookup misses.

RFC 4512 §2.5: attribute type names (descriptors) are case-insensitive. A server is free to return givenname, GIVENNAME or givenName; the client has to match them as equal. Any server that normalises attribute names (LLDAP does; some AD-facing proxies do too) hits this.

Suggested fix: compare attribute names case-insensitively when reading a SearchEntry (e.g. lower-case both the requested name and the returned keys once, or look the key up through eq_ignore_ascii_case), for givenName, sn, mail, uniqueMember and every other attribute read by name.

How to reproduce: LLDAP 0.6.3 with one user that has a first name, Defguard 2.1.0 pointed at it with the settings above, run the LDAP sync, read the Core log.

I can test a patch against the same lab within a day.