Exchange 2019 + ADFS is it possible to configure ModernAuth for third-party Android mail clients?

Hello,

Our organization operates under Uzbekistan's data localization and banking secrecy regulations, which require customer and corporate data — including email — to remain on infrastructure physically located within the country and under direct regulatory oversight. This precludes the use of cloud-hosted mail services such as Microsoft 365/Exchange Online, and requires a fully on-premises Exchange deployment with local identity federation (AD FS) instead of Azure AD.

Environment:
Exchange Server 2019 CU14, single server (MX01), pure on-premises.
AD FS is registered as an AuthServer (Type: ADFS), no Azure AD / hybrid tenant involved.
The AuthServer is configured correctly: AuthorizationEndpoint and TokenIssuingEndpoint are populated, IsDefaultAuthorizationEndpoint: True, and DomainName points to our mail domain. Realm/ServiceName are configured as well.

Symptom:
The native iOS Mail client (account added manually, no MDM profile) correctly redirects to our AD FS login page on first setup — the full Modern Auth flow works.

A third-party EAS client (Nine by NitroDesk, Android) never receives an OAuth challenge at all — it falls back to Basic authentication.

Get-ActiveSyncVirtualDirectory/Set-ActiveSyncVirtualDirectory in this build simply has no -OAuthAuthentication parameter (unlike EWS/OAB).

Log finding:
When testing with the Nine client, the following was captured in the Exchange HttpProxy/Eas logs:

S:ServiceCommonMetadata.OAuthError=Flighting is not enabled for domain 'webmail.<domain>'. S:ServiceCommonMetadata.OAuthErrorCategory=OAuthNotAvailable

Questions:

1. What exactly controls "Flighting" for EAS OAuth in a pure on-prem Exchange 2019 CU14 + AD FS scenario (no Azure AD)? Is there a documented, supported way to enable it (New-FlightOverride? something else)?
2. Is EAS Modern Auth even supported for an arbitrary/generic OAuth client (not Apple, not Outlook) in this scenario, or is it effectively an allowlist limited to specific client_ids (Apple Native Mail / Outlook)?
3. How does native iOS Mail get redirected to AD FS without ever receiving an authorization_uri in the EAS/Autodiscover 401 challenge — is there an undocumented discovery path (e.g., hardcoded per registered client_id)?

Thank you in advance for any insight.