#39989 feat: email filtering in `users.info` and `users.list` endpoints

Proposed changes (including videos or screenshots)

• users.info
  • UsersInfoParamsGet.ts validation schema was extended so that email is accepted as query parameter.
  • getFullUserData.ts was modified to support email lookup only if the user is looking for their own info or if the user view-full-other-user-info permission they would be able to look for other users by email.
• users.list
  • UsersListParamsGET.ts was brought from this open PR, with the additional email property.
  • Implemented case-insensitive matching ($regex + $options: 'i') to align with database collation and users.info behavior.
  • The new email filter is intentionally injected into the nonEmptyQuery object rather than creating a separate database query. This is done to maintain backward compatibility with the legacy query parameter. By merging them, both explicit parameters and legacy queries can work together seamlessly until the legacy query parameter is officially removed.
• Added tests covering cases where users.info and users.list are queried with email.
• Removed obsolete test for the name query parameter on /api/v1/users.list. Manually verified that the endpoint completely ignores this parameter. Passing complex objects or regex operators (e.g., ?name[$regex]=...) returns the exact same full array as an empty request. Dropping this test removes dead code and prevents future confusion.

Issue(s)

CORE-1994 [Feature Request]: Add Email filter to users.info and users.list endpoints

Steps to test or reproduce

Using an API client and having two users: one with the view-full-other-user-info permission and the other one without it. We have to get the X-Auth-Token and X-User-Id values for each one and set them on the Headers section.

• For users.info: Try fetching info of any user if the requester has the view-full-other-user-info permission, or if the requester doesn't, then try to fetch their own info (same email), and they shouldn't be able to fetch others data.
  Example URL:http://localhost:3000/api/v1/users.info?email=email@example.com
• For users.list: In this case, only the user with the view-full-other-user-info is able to fetch by email and they must be able to see the emails property from each user in the response payload. Users without the permission, shouldn't be able to fetch by email (unauthorized) but they can call users.list without any query parameter, with the exception that the emails property isn't shown to them.
  Example URL: http://localhost:3000/api/v1/users.list?email=test@rocket.chat

Further comments

Summary by CodeRabbit

• New Features

  • Email-based search support for user listing and user info endpoints; queries by email now available and subject to permission checks.

• Tests

  • Added end-to-end tests for email-based user queries covering success, not-found, and permission-denied cases.