domain_hint with an Okta issuer host is intercepted by home-realm discovery instead of selecting the custom OIDC provider (External ID external tenant)

We have a Microsoft Entra External ID external tenant with a self-service sign-up user flow containing a single custom OpenID Connect identity provider that federates to an Okta org

• Issuer: https://<org>.okta.com
• Well-known endpoint: https://<org>.okta.com/.well-known/openid-configuration
• The provider works correctly when the user clicks its button on the sign-in page.

For custom OIDC providers whose issuer is login.microsoftonline.com, we can skip the sign-in page by sending domain_hint=login.microsoftonline.com (issuer-host acceleration). We want the equivalent behavior for the Okta provider.

Problem: sending domain_hint=<org>.okta.com on the /oauth2/v2.0/authorize request never reaches the custom OIDC provider. Instead, the request is captured by Microsoft home-realm discovery: because <org>.okta.com happens to resolve as a federated Microsoft 365 domain, the response is a 302 to a WS-Fed endpoint (.../app/office365/.../sso/wsfed/passive?...wtrealm=urn:federation:MicrosoftOnline) a completely different federation path than the OIDC provider configured in the tenant, and one that cannot complete our sign-in.

So for Okta-issued providers there appears to be no domain_hint value that selects the configured custom OIDC identity provider — Microsoft-domain values accelerate to the wrong realm, and non-Microsoft values are either intercepted (as above) or ignored.

Question: for a custom OIDC identity provider whose issuer is an Okta org URL, is there any supported domain_hint value (or other authorize-request parameter) that routes the user directly to that provider, skipping the sign-in page? Or is the sign-in page unavoidable for non-Microsoft OIDC issuers in external tenants today?

Related question about the general domain-routing scenario: https://learn.microsoft.com/en-us/answers/questions/5964766/how-to-route-users-directly-to-a-custom-oidc-ident