it looks like the primary group internally changed from 5000(eng) to 89939(primarygroup) because $reasons

the sdk was not written to handle this scenario.  it assumes the primary group never changes.  you can see this in:
src/scripts/sdk_lib/make_chroot.sh:
  # Set up users, if needed, before mkdir/mounts below.
  [ -f $CHROOT_STATE ] || init_users

so we initialize the passwd & groups entries once at chroot creation and never again.

we can detect this scenario by comparing the active SUDO_GID to the primary group of the user in the chroot.  if they differ, we should:
- create the new group
- change the user's primary group to the new group
- issue a warning about the change

i think this should be OK because:
- the old primary group should still be listed as a supplemental group
- our enter logic will change the uid, primary gid, and supplemental gids to the registered values inside the chroot
- any existing files owned by the old primary group will still be accessible
- any new files will change group to the new primary group

we could conceivably detect changes in UID too, but in that scenario, just complain & die ?

people in the meantime can mitigate this with something like:
  cros_sdk -- sudo groupadd -f -o -g $(id -g) $(id -gn)
  cros_sdk -- sudo usermod -g $(id -g) $USER
then exit/enter any existing sessions.