Admin Settings: audit card hierarchy and promote nested sub-cards to sibling cards

Summary

Over time, Admin Settings has accumulated cards nested inside other cards. In a lot of cases the nested card is really its own top-level feature — it just happens to be gated by a toggle on the card above it, so it got dropped inside that card instead of sitting next to it as a sibling.

We want to walk through each major card in Admin Settings, one by one, and decide whether each sub-card should stay nested or be promoted to a sibling (parent-level) card.

Why this matters

• Discoverability — settings buried two or three levels deep are hard to find. Admins have to know which parent feature owns a setting before they can locate it.
• Navigation/linking — nested cards are hard to link to. The admin side panel / Admin Settings navigation and the sidebar can't cleanly deep-link to something that isn't a first-class card.
• Mental model — nesting implies "this is part of that feature." When a nested card is actually its own feature that happens to depend on a toggle above it, the nesting communicates the wrong relationship.

Being gated by an upstream toggle is a dependency, not a reason to be a child card. A sibling card can be disabled/hidden by its dependency and still be a first-class card.

Scope

Go through each major card across the Admin Settings tab groups and their panes:

• application/single_app/templates/admin_settings.html (tab shell + nav)
• application/single_app/templates/admin/_panes/*.html (~46 panes: secrets, access-roles, content-safety, session, agents, actions, inbound-mcp, feature-governance, governance-policies, mcp-governance, logging, branding, notices, custom-pages, model-endpoints, embeddings, image-generation, control-center-config, backup, migrate, restore, cosmos-editor, jobs, redis-caching, cosmos, network, workspace-identities, file-sync, workspace-types, files-sharing, workflow, retention, classification, archiving, citation, chat-experience, feedback-alerts, web-research, search-index, extraction, audio-video, support-menu, send-feedback, latest-features)

For each major card, capture:

1. What sub-cards exist inside it today.
2. For each sub-card: is it genuinely part of the parent feature, or is it its own feature that's merely gated by the parent?
3. If it's its own feature — promote it to a sibling card, and keep the gating behavior (disabled/hidden when the dependency is off) without the nesting.
4. Whether the promoted card needs its own entry in the Admin Settings navigation / side panel / sidebar so it can be found and linked to directly.

Approach

This is an audit-first task. Suggest doing the inventory pass and agreeing on the promote/keep decisions before any template restructuring, so we don't churn markup while the model is still being decided. Restructuring can then land incrementally, ideally grouped by tab rather than one giant change.

Out of scope

• Renaming or changing the behavior of individual settings.
• Adding new settings or features.
• Redesigning the visual style of the cards. This is about hierarchy and placement, not aesthetics.

Acceptance criteria

• Every major Admin Settings card has been reviewed, with its sub-cards inventoried.
• Each sub-card has a documented decision: keep nested (with rationale) or promote to sibling.
• Promoted cards render as first-class sibling cards while preserving their gating dependency.
• Admin Settings navigation / side panel and sidebar entries updated so promoted cards are reachable and linkable.
• Docs under docs/admin/ updated to match the resulting structure.
• docs/_data/app_surface.yml regenerated (python .\scripts\build_docs_inventory.py) and coverage tests pass.