Contractor: How to describe features defined for instances, groups, and projects
<!--IssueSummary start-->
<details>
<summary>
Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards.
</summary>
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=577372)
</details>
<!--IssueSummary end-->
### Problem to solve
> [!important] 2025 update
> The current docs guidance advises against using "level": https://docs.gitlab.com/development/documentation/styleguide/word_list/#level
The docs use the word "level" in many different ways. Some examples:
- project level
- group level
- instance level
- cluster level
- chart level
- access level
- permission level
- visibility level
- top-level directory
- third-level heading
- the customer's level of flexibility
- the top-level interface
- level of uptime
While "level" can be helpful to express that things build on other things, if you are a new user and you don't understand the "levels," you might be confused. We should strive to be as specific as possible.
Side note: During a Runner meeting, we noticed that some teams are using different icons/indicators for features defined for the instance, group, and project, so we should probably sync with UX on icons/usage.
### Proposal
I'd like to remove the word "level" as much as possible. When a feature is defined for the instance, group, or project, we can use language like, "For the instance, ..." or "For the project or group, ..."
Here are some example re-writes, pulled straight from the docs.
Example 1:
- Now: `The total number of instance level CI/CD variables is limited at the instance level.`
- Proposed: `For your instance, the total number of CI/CD variables you can use is limited.`
Example 2:
- Now: `To preserve group-level relationships from imported projects, run Group Import/Export first, to allow project imports into the desired group structure.`
- Proposed: `To preserve group relationships from imported projects, run Group Import/Export first, to allow project imports into the desired group structure.`
Example 3:
- Now: `Use instance-level or group-level default settings for a project integration`
- Proposed: `For the instance or group, use default settings for a project integration`
issue