fix: drop legacy app_super_admin -- SUPER_ADMIN_GROUP is now god_admin (v1.26.1)

god_admin now exists at boot (seeded by docker-entrypoint), so the canonical
cross-resource super group nested into every resource's _admin group is god_admin,
not the legacy app_super_admin. docker-entrypoint no longer seeds or nests
app_super_admin (god_admin nests into the app_sso_* groups directly). isSuperAdmin
still recognizes a pre-existing app_super_admin as a migration alias until rebuild.

docker-entrypoint.sh

@@ -359,7 +359,7 @@ EOF
     # god_admin is the global super group (docs/GROUPS.md §2), the top of the
     # group-inheritance lattice. It is seeded here so it exists from first boot;
     # the theta-suite bootstrap puts the first admin person into it.
-    for group in god_admin app_super_admin app_sso_admin app_sso_invite app_sso_oauth_admin app_sso_service_account; do
+    for group in god_admin app_sso_admin app_sso_invite app_sso_oauth_admin app_sso_service_account; do
         ldapadd -x -D "$LDAP_BIND_DN" -w "$LDAP_ADMIN_PASS" -H ldap://localhost:389 << EOF || true
 dn: cn=${group},ou=groups,${LDAP_BASE_DN}
 objectClass: groupOfNames
@@ -370,11 +370,11 @@ member: ${LDAP_BIND_DN}
 EOF
     done
 
-    # Nest app_super_admin into the SSO admin groups, so cross-app super admins
-    # hold those rights by membership rather than by a special case in app code.
-    # This is what makes the privilege visible to every consumer -- SSSD, sudo,
-    # anything binding LDAP directly -- instead of only to callers that happen
-    # to route through utils/permission.js.
+    # Nest god_admin into the SSO admin groups, so god admins hold those rights
+    # by membership rather than by a special case in app code. This is what makes
+    # the privilege visible to every consumer -- SSSD, sudo, anything binding
+    # LDAP directly -- instead of only to callers that happen to route through
+    # utils/permission.js.
     #
     # app_sso_service_account is deliberately excluded: it is a marker for
     # non-person accounts, not a permission, and nesting admins into it would
@@ -385,21 +385,10 @@ EOF
 dn: cn=${group},ou=groups,${LDAP_BASE_DN}
 changetype: modify
 add: member
-member: cn=app_super_admin,ou=groups,${LDAP_BASE_DN}
-EOF
-        done
-        info "Nested app_super_admin into the SSO admin groups"
-
-        # god_admin is the top of the lattice; nesting it into app_super_admin
-        # (which is itself nested into the app_sso_* groups above) makes it
-        # resolve to everything app_super_admin holds at the LDAP level too.
-        ldapmodify -x -D "$LDAP_BIND_DN" -w "$LDAP_ADMIN_PASS" -H ldap://localhost:389 >/dev/null 2>&1 << EOF || true
-dn: cn=app_super_admin,ou=groups,${LDAP_BASE_DN}
-changetype: modify
-add: member
 member: cn=god_admin,ou=groups,${LDAP_BASE_DN}
 EOF
-        info "Nested god_admin into app_super_admin"
+        done
+        info "Nested god_admin into the SSO admin groups"
     fi
 
     info "LDAP directory initialized"