Include project ancestors when determining agent user access

What does this MR do and why?

Fixes a bug where group authorisations for agent user access included only the specific group authorised, and not their subgroups. If a group is authorised, all subgroups should inherit this access.

Database changes

See !167868 (comment 2142230432).

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

How to set up and validate locally

1. Create a group hierarchy as shown in #432685 (closed), with a top-level group and a subgroup.
2. Create a project in the top level group, and register an agent with the following configuration (note that the agent must be able to connect to your GDK, otherwise KAS won't send the configuration through and the authorisations won't be persisted):

    user_access:
      access_as:
        agent: {}
      groups:
        - id: <YOUR TOP LEVEL GROUP PATH>

3. Create a project in the subgroup, and go to Operate -> Environments -> New Environment. In the GitLab agent dropdown, you should see the agent you created above:

Related to #432685 (closed)