Why is this obscure property necessary for Google Admin API to confirm that someone is a member of a Google Group?

I stood up OAuth2-proxy as a reverse proxy in front of my application, following their instructions. The reverse proxy uses Google accounts for authentication, and uses an existing Google Group for authorization, per those same instructions.

Everything works for some lucky members of the group. Other cursed members of the group are refused access.

Logs reveal that the Google Admin API is responding that each of the lucky emails is in fact a member of the group, but each of the cursed emails is errantly reported as not a member of the group.

What is the difference between the lucky and the cursed? Examining https://console.cloud.google.com/iam-admin/groups/ for my organization and project shows a table with a curious Type icon.

All five of the group members with the icon are lucky: the Google API confirms they are members of the group. All four members without the icon are cursed.

The type icon is associated with the type google.apps.cloudidentity.groups.vx.membership.type.user. The five lucky members all have this type. The four cursed members do not. What is this type? It is mentioned nowhere in the public internet, until this SO question is posted.

Consider the two test emails freddiehubbard1971@yahoo and milesdavis1959@yahoo.com. Freddie and Miles were created at the same time. They are both Yahoo emails, with associated Google accounts. They are alike in every way, except somehow Freddie is lucky and Miles is cursed.

How did Freddie get tagged with google.apps.cloudidentity.groups.vx.membership.type.user and Miles did not? And more importantly how can I ensure that the non-test members of the group are so tagged?

Posting my answer from the comments for future references:

That icon usually indicates that the email address does not belong to a Google account. I was able to reproduce the exact same behavior by adding to a group an email address of a user who does not have a Google account.

The workaround for this is to just remove the email address from the group and add it again after making sure that the user has an active Google account with that email address.

Explanation:

This is not a bug or an issue, but an actual expected behavior due to how Google Groups and OAuth2 Proxy works, as it was mentioned in the post:

The reverse proxy uses Google accounts for authentication, and uses an existing Google Group for authorization, per those same instructions.

This means the app depends on an actual Google account to work correctly, and requires a GAIA ID which is only assigned to temporary and actual Google accounts.

Since the user before being added to the group did not have a Google account, and just adding an email address to a Google group does not create any temporary Google account (also called Nori accounts), then the OAuth2 Proxy app does not have any way to connect to this email address in the group.

Now, on the other hand, when the user created the Google account, then a GAIA ID was assigned to that email address, but the user was "stuck" in the group as a simple string of text that was part of the mailing list because it was added before creating the Google account, and the only way to change that would be adding the account again so the system can recognize the Google account, and associate the email address with the GAIA ID and that way the app will be able to recognize the user being part of the group and grant access.