Artifact Signing organization representative validation: matching Microsoft account alias still receives "You need permission"

We need help restoring access to an existing Public Trust organization identity-validation request. The signing account is in East US on an active paid Azure subscription. The request is in Action Required and its portal banner says to complete verification.

Following either the original verification email or the existing request's portal continuation link reaches credentials.microsoft.com/verify/noPermission after successful sign-in. The page says "You need permission" and says the signed-in user must be an authorized user of the Entra tenant used for the enrollment.

Checks completed:

• The company-domain primary verification email is a verified alias of the same personal Microsoft account that created the request. It is now the primary alias; the original Gmail alias remains.
• The verification page displays the matching company email, but still denies access.
• We signed out, entered the original Gmail sign-in name explicitly, and signed in with the existing passkey. The same denial remains.
• The same Entra user has subscription Owner and Artifact Signing Identity Verifier on the signing resource. There are no deny assignments.
• The directory user is enabled, Member, and described by the portal as an external B2B user with MicrosoftAccount as its federated identity issuer. The directory contact email is blank; no directory properties have been changed.
• The page reports the shared Microsoft personal-account tenant. The Azure resource is in the subscription's own directory. This difference alone does not establish an incorrect enrollment binding.
• The request was created before the primary-alias change. The original email arrived today; no expired-link message is shown.

Please have the Artifact Signing identity-validation team confirm:

1. Is the existing personal Microsoft account supported for this organization representative step?
2. Which supported action restores the existing enrollment's authorization when the email matches and Azure roles are present?
3. If a native Entra work account is required, how should it be associated with the EXISTING request without creating a duplicate paid resource or discarding the current request?

Azure support has directed this identity-validation issue to Microsoft Q&A. We can provide subscription, tenant, user-object and request identifiers privately to an authorized Microsoft engineer. This public post deliberately omits those identifiers, account email addresses, authentication links, financial records, and identity documents.