Custom group project template creation fails for Developers - wrong template_project_id submitted
## Summary
Developer users cannot create a project from a custom group template. The UI submits an **old/incorrect template project ID** instead of the expected template project ID, resulting in the error:
```
Template project <id> is unknown or invalid.
```
This appears to be a regression introduced around the time the `constrain_group_project_templates` feature flag was enabled. The new `Projects::GroupTemplatesFinder` code path likely resolves templates differently when duplicate template names exist across group hierarchies, returning an old/stale template instead of the correct one.
Only users with the **Developer** role are affected. Users with the **Owner** role can create projects from the template successfully.
## Steps to Reproduce
1. Set up a group with a custom project template subgroup containing a template (e.g. `my-template`)
2. Ensure there is another group in the hierarchy that also has a template with the same name (`my-template`) that the Developer does **not** have access to
3. Log in as a user with the **Developer** role in the target group
4. Navigate to create a new project from a custom group template
5. Select the template from the template picker
6. Attempt to create the project
7. Observe the error: `Template project <id> is unknown or invalid`
## What is the current *bug* behavior?
The form submits the wrong `template_project_id` and `group_with_project_templates_id` — pointing to an old/inaccessible template rather than the one the user selected. HAR analysis confirms the `POST` to `/projects` contains incorrect IDs.
Additionally, the template picker may show templates the Developer does not have access to.
## What is the expected *correct* behavior?
- The form should submit the correct `template_project_id` corresponding to the template the user selected
- The template picker should only show templates the user has access to
- Developers should be able to create projects from custom group templates they have access to, just as Owners can
## Suspected Cause
The `constrain_group_project_templates` feature flag rollout and the associated `Projects::GroupTemplatesFinder` changes may have introduced a regression in how templates are resolved when duplicate template names exist across group hierarchies. The resolver appears to return the wrong template when names collide.
Related:
- [Improve group template selection when creating projects](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/235297)
- [FF: `constrain_group_project_templates`](https://gitlab.com/gitlab-org/gitlab/-/work_items/586332)
## Offering
- GitLab.com (SaaS)
issue