Microsoft 365 OAuth: popup reports "account connected" but parent window shows "Authorization pop-up closed" and no account is created

Steps to reproduce

1. Configure Microsoft OAuth in Groupware → Microsoft Integration (Client ID, Secret, tenant common). Confirmed saved and persisting after a hard reload of the admin page.
2. Azure app registration: redirect URI is an exact, character-for-character match to https:///index.php/apps/mail/integration/microsoft-auth, registered under the Web platform (not SPA). Admin consent granted successfully.
3. In the Mail app, add an account via the Auto path (email + placeholder password) → Connect.
4. Complete sign-in and consent in the Microsoft popup; the popup reaches "Account connected / you can close this window."

Expected behavior

The account is created and the mailbox loads.

Actual behavior

While the Microsoft popup is still open and showing success, the underlying account-setup box in the parent window already displays "Authorization pop-up closed." After closing the popup, the Mail app returns to the login screen with no account in the sidebar — the account is never created. This appears similar to the symptom in issue #9159.

Mail app version

5.9.1

Nextcloud version

33.0.5

Mailserver or service

Microsoft 365 / Exchange Online (XOAUTH2)

Operating system

Linux

PHP engine version

Other

Nextcloud memory caching

No response

Web server

Apache (supported)

Database

MySQL

Additional info

Browser: Reproduces in Microsoft Edge with a clean/default profile, third-party cookies and popups allowed for the Nextcloud domain and login.microsoftonline.com. Also reproduces in Chrome.
Hosting: Managed Nextcloud (Cloudamo) — I do not have shell/occ access, and the in-browser admin log viewer shows no entries.

Additional context / already ruled out: Credentials are in the correct Mail-app panel (redirect URI path is /apps/mail/), saved server-side. Azure redirect URI is an exact match and registered as Web, not SPA. IMAP is enabled on the mailbox; admin consent succeeded after elevating the Azure role. Browser-side causes ruled out via clean Edge profile with cookies/popups allowed.

Given the "Authorization pop-up closed" message appearing before the popup completes, is this a known front-channel/callback handling issue, and what server-side configuration (e.g. overwrite.cli.url, overwriteprotocol/overwritehost, trusted_domains, or reverse-proxy rewriting of the /index.php/apps/mail/integration/microsoft-auth path) would cause the parent window not to receive the popup's result? I'm on managed hosting and would like to give the host a precise instruction if this is on their side.