Generates `cannot follow backlink ... because link ... is computed` with certain access policy

[jackfischer]

Version: 3.5 and 4.0-rc.2

1. Migrate up to the schema below
2. Insert some data,

   configure session set apply_access_policies := false;
   insert User {organization:=(insert Organization)};

3. Browse to /ui/edgedb/data/default::User

4. UI generates the following query which fails, receive "Failed to fetch data" error

   WITH
   baseObjects := (select default::User),
   rows := (SELECT baseObjects  ORDER BY  .id OFFSET <int32>$offset LIMIT 100)
   SELECT rows {
     id,
   
     __count_organization_0 := (for g in (
             group (
               with sourceId := .id
               select default::Organization
               filter .<organization.id = sourceId
             )
             using typename := .__type__.name
             by typename
           ) union {
             typename := g.key.typename,
             count := <std::float64>count(g.elements)
           })
   }

error: InvalidReferenceError: cannot follow backlink 'organization' because link 'organization' of object type 'default::AuditLog' is computed

Schema:

using future nonrecursive_access_policies;

module default {

    global current_user: uuid;
    global current_user_object := (
        select User filter .id = global current_user
    );

    type Organization {
        access policy allow_select_users
            allow select
            using (global current_user_object.organization.id ?= .id);
    }

    type AuditLog {
        required link user: User;
        required single link organization := .user.organization;
    }

    type User {
        required link organization: Organization;
    }

}

Similar to https://github.com/edgedb/edgedb-ui/issues/185

[jackfischer]

~This may be a compiler issue but filed here for now because it's how I discovered it and am not sure about the nuances of reducing the UI-generated query~ Seems like a quirk of how this group by on .__type__.name is generated. When there is a computed with the same name that's picked up. It seems like this just requires not using the groupby and instead generating all the (valid) types into the query :/

[jackfischer]

Another issue related to this specific access policy: https://github.com/edgedb/edgedb/issues/6404

[jackfischer]

Thank you!