$search on /graph/v1.0/users omits mail field, breaking the space/file member-invite autocomplete #4039

Describe the bug

Inviting a user to a Space (or sharing a file/folder) via the "Add members" search field shows "No users or groups found" even though the backend correctly finds the user. The $search-filtered response from /graph/v1.0/users is missing the mail field (present on the same user via the unfiltered admin listing), and the invite-autocomplete component appears to require/key off mail, silently dropping matches that lack it.

Steps to reproduce

Step 1: Create a test LDAP user (e.g. uid=sharetest, mail=sharetest@example.com, displayName=Share Test User)
Step 2: As a Space Admin, open a Space -> Members -> type the username (sharetest) in the search field
Step 3: Observe the network request GET /graph/v1.0/users?$search="sharetest"&$orderby=displayName returns 200 with the correct match (confirmed via intercepted XHR):

{"value":[{"displayName":"Share Test User","id":"6c7a56ee-4582-35a7-b3b2-57af9a76e0b2","onPremisesSamAccountName":"sharetest","userType":"Member"}]}

Step 4: The invite dropdown still renders "No users or groups found."

Expected behavior

The user should appear in the autocomplete dropdown and be selectable as a member/collaborator.

Actual behavior

The dropdown always shows "No users or groups found", even though the underlying $search API call returns the correct user. Public/password-protected share links are unaffected and work correctly, so this is isolated to the nominative invite-search UI.

Setup

Self-hosted OpenCloud 7.4.0 (rolling), authentication via an external LDAP server (not the embedded IDM), decomposeds3 storage backend. Relevant environment variables:

OC_LDAP_URI=ldap://<ldap-host>:3890
OC_LDAP_BASE_DN=dc=example,dc=com
OC_LDAP_USER_BASE_DN=ou=people,dc=example,dc=com
OC_LDAP_USER_OBJECTCLASS=inetOrgPerson
OC_LDAP_USER_SCHEMA_ID=entryuuid
OC_LDAP_GROUP_BASE_DN=ou=groups,dc=example,dc=com
OC_LDAP_GROUP_OBJECTCLASS=groupOfUniqueNames
STORAGE_USERS_DRIVER=decomposeds3

Additional context

Confirmed by intercepting the app's own XHR request/response (not a manual reproduction with a separate client) that the backend response for $search queries omits mail, while the same user's record includes mail when listed without $search filtering as an Admin. This strongly suggests the $search code path uses a reduced LDAP attribute projection that drops mail, and the frontend invite component depends on that field being present.