Move user settings into the profile sidebar disclosure and stop pinning settings

What does this MR do and why?

Behind the hide_unpinned_sidebar_items feature flag, settings for groups, projects, and admin areas open from the sidebar footer disclosure. User settings had their own sidebar, so moving between your profile and your settings swapped the whole navigation.

With the flag on:

• Profile sidebar: your own profile sidebar gets a User settings button in its footer, above Help. It lists the user settings pages, built from Sidebars::UserSettings::Panel so EE additions (Billing, GitLab Credits) come along. It only renders when you are signed in and viewing your own profile; other users' profiles, including when an admin views them, don't get it.
• User settings pages: they keep your profile sidebar instead of the User settings sidebar. The button shows as selected, and the current page is active inside the dropdown.
• Nested sections: the dropdown lists single pages first, then nested sections such as Access as a headed group (menu_section.vue). Group, project, and admin dropdowns have no nested sections, so they look the same.
• Edit profile: the "Profile" link in the dropdown reads Edit profile, reusing the existing UserProfile|Edit profile string.
• Command palette: it now lists pages of sections nested one level deeper, for example "Settings > Access > SSH keys". Other sidebars produce the same links as before.

With the flag off, user settings pages keep the User settings sidebar, and nothing changes.

Settings pins (merged in from !265263 (merged))

With the flag on, in group and project sidebars:

• Footer disclosure: the settings dropdown has no pin controls.
• Pinned section: settings pages a user pinned earlier no longer show in the pinned section, including the compact grouped view and Full mode.
• Saved pins are kept: every pin change sends the full list of pin IDs to the server, so settings pins are hidden only in what the sidebar displays. They stay in pinned_nav_items through pin, unpin, and reorder, and turning the flag off brings them back.

Unchanged: the flag-off sidebar, the Organization sidebar, and the Feature catalog (which already excludes Settings). Users::PinsController still accepts any item ID, so the restriction is UI-only.

Relationship to the rest of the stack

Like the Admin area and Organization admin panels — whose labels are defined in !265260, the MR that makes them reachable — this MR introduces Sidebars::UserProfile::Menus::SettingsMenu itself, so it carries its own disclosure_title override (User settings). The disclosure_title mechanism comes from !270748 (merged), merged into !270747 at the base of the stack.

It also adds two panel types (profile, user_profile) to the panel map and renames it to match what it now describes:

ADMIN_PANEL_SETTINGS_MENU_ITEM_IDS → PANELS_WITH_FOOTER_SETTINGS_DISCLOSURE

The old name was accurate when the map held only admin panels; with the profile panels added it no longer is. The new name says what the map is for — which panels put their Settings section in the footer disclosure — rather than naming a placement, so it stays accurate as more panels join.

Stack (3 of 3): footer placement (!270747) → Admin area (!265260) → this MR.

Settings pins (!265263 (merged)) has been merged into this branch, so this MR also stops settings pages being pinnable; see Settings pins below. Disclosure labels (!270748 (merged)) and organization admin (!265261 (merged)) are merged further down the stack.

Notes for reviewers

• Performance: viewing your own profile now builds the User settings menu. On SaaS this adds one memoized query (groups_with_gitlab_credits.any? in GitlabCreditsDashboardMenu#render?). Previously it only ran on settings pages.
• QA: qa/qa/page/profile/menu.rb won't find the user settings links once the flag is on in staging. Group and project settings already have the same exposure on master.
• Follow-up: Access renders as a headed group for now. Once the Pajamas nested dropdown (gitlab-org/gitlab-services/design.gitlab.com!6241 (closed)) ships in @gitlab/ui, it can become a submenu.

References

• Targets: !265260
• Merged in: !265263 (merged)
• Rollout issue: #604888
• Related: #621643

Screenshots or screen recordings

User settings

Before	After

Settings pins (from !265263 (merged), merged in)

Before	After

How to set up and validate locally

1. Enable the feature flag in the Rails console:

   Feature.enable(:hide_unpinned_sidebar_items)

2. Visit your own profile, for example /root. Confirm a User settings button appears in the sidebar footer, above Help.

3. Open it. Confirm single pages (starting with Edit profile) are listed first, followed by an Access group with its own heading.

4. Go to a settings page, for example /-/user_settings/ssh_keys. Confirm the profile sidebar stays, the button is selected, and SSH keys is selected in the dropdown.

5. Collapse the sidebar to icon-only and confirm the tooltip reads User settings.

6. Visit another user's profile and confirm there is no settings button.

7. Open the command palette and search for "SSH keys". Confirm "Settings > Access > SSH keys" is listed.

8. Visit a project, a group and /admin, and confirm their disclosures are unchanged by the constant rename (Project settings / Group settings / Admin settings).

Settings pins (merged in from !265263 (merged)):

1. With the flag off, visit a project and pin a settings page, for example Settings > General.
2. Enable the flag and reload. Confirm the settings pin no longer shows in the sidebar, and the footer settings dropdown has no pin buttons.
3. Unpin or reorder another pinned item, then disable the flag and reload. Confirm the settings pin is back.
4. Disable the flag and confirm user settings pages show the User settings sidebar again.

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.