Add empty state for group-level branch rule at project level

Backend extracted: the GraphQL slice now lives in Expose isGroupLevel on the BranchRule GraphQL type (!246781) per the multiversion-compatibility review, and this MR is marked as blocked by it. Once !246781 (merged) merges, this branch rebases onto master and the backend commits drop out, leaving the frontend-only diff.

What does this MR do and why?

Navigating by URL to a group-level branch rule on the project-level branch rule details page (/-/settings/repository/branch_rules?branch=<group-rule>) misbehaved for every permission level:

• A user who can administer the group saw a bare "No data to display" string, because Filter out group-level rules from details page (!208771) excludes group-level rules from the page without explaining where the rule lives.
• A user without group permissions saw a broken-looking full details page: BranchProtection is authorization-gated (read_protected_branch on the group), so branchProtection resolves to null for them and the rule slips the isGroupLevel filter, rendering empty access levels with live Edit and Delete buttons.

The second case also means the frontend had no permission-independent way to detect a group-level rule. The MR therefore has two parts:

1. Backend: a rule-level isGroupLevel field on the BranchRule GraphQL type (EE), readable by every user who can read the rule, unlike the equivalent field on BranchProtection. It also replaces a vacuously passing request-spec assertion (string id compared with a GlobalID object) that had hidden the null-protection behavior.
2. Frontend: the details page detects the group-level case with the new field and renders the empty state agreed in the issue thread: "Setting inherited" with the empty-groups-md illustration. Copy is permission-conditional per the thread's final table (TW approved). With group admin permission: "This branch rule is configured for the group. To make changes, go to group repository settings." plus a "View group repository settings" button (the groupSettingsRepositoryPath already provided for the group-inheritance popovers). Without: "This branch rule is configured for the group. You do not have the required permissions."

The genuine non-existing-rule case keeps the existing "No data to display" text. Group-level rules only exist under EE, so CE behavior is unchanged.

Resolves Add empty state when user tries to view a group-level branch rule on the project level (#577324).

References

• Add empty state when user tries to view a group-level branch rule on the project level (#577324), with the agreed design and copy in-thread
• Filter out group-level rules from details page (!208771), which introduced the filtered state

Screenshots or screen recordings

View	Before	After
Group admin, light
Group admin, dark
Project maintainer without group access (second defect: nulled protection rendered a broken details page)

How to set up and validate locally

1. Use a GDK with an EE license. In a root group, go to Settings > Repository > Protected branches and protect a branch (for example release), so the group has a group-level branch rule.
2. In a project inside that group, visit Settings > Repository > Branch rules. The group rule appears in the list with a lock icon and no View details.
3. Hand-edit the URL to the details page for that rule: /<project>/-/settings/repository/branch_rules?branch=release.
4. As a user who can admin the group: the "Setting inherited" empty state renders with the "View group repository settings" button.
5. As a project maintainer without group access: the same empty state renders with the no-permissions copy and no button (previously: a broken details page with empty access levels and live Edit and Delete buttons).
6. Visit the same URL with a made-up branch name: "No data to display" still renders.

MR acceptance checklist

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