Admin Settings IA stage C: group navigation rendered from one definition

[Paul Lizer (paullizer)]

Stage C of the Admin Settings information architecture rework. Targets the feature/admin-settings-ia staging branch.

No cards move in this PR. The group level is added against the current 18 tabs, so grouping is proven against a known-good tab set before stage D starts re-homing anything.

The problem underneath

Admin Settings presented 18 tabs in one flat list — and that list was written out twice, once as the top tab strip and once as the sidebar. Two hand-maintained copies of the same structure, which had predictably diverged:

	Top tab strip	Sidebar
agents	"Agents"	"Agents and Actions"
custom-pages	"Custom Pages"	"Static Pages"
search-extract	"Search and Extract"	"Search & Extract"
Tab order	one order	a different order

Adding a group level to two hand-maintained lists would have doubled that problem. So both now render from admin_settings_nav.py.

What changed

Navigation is one definition. ADMIN_NAV describes groups → tabs → sections. Both navigations render from it, so a change is made once and appears in both.

The map was generated from the existing sidebar markup, not retyped — faithful by construction. I then rendered the sidebar before and after and diffed the destinations:

before: 18 tabs, 86 sections
after:  18 tabs, 86 sections, 12 groups
per-tab section order preserved for all 16 tabs

The group level. Sidebar groups are collapsible and remember their state per user. The tab layout gets a row of group pills that filters the strip to one group, which keeps a single row readable as tabs multiply.

Opening a tab reveals its group first in either layout, so a deep link or a data-admin-link cross-reference can never activate a pane whose tab is collapsed or filtered out of view.

Search now spans three levels — group, tab and setting — and expands whatever it needs to show a result.

A gap the equivalence check found

Diffing rendered destinations surfaced something I'd otherwise have missed: shared-conversation-file-approvals-section had no navigation entry at all.

That card arrived upstream while this work was in flight, and could only be found by scrolling the AI Models tab. It's now listed like every other setting — which also clears a pre-existing parity failure, taking the regression baseline from 33 down to 32.

Tests now assert on the contract, not on one rendering

Several tests scraped literal sidebar markup that is now generated. Rather than teach them to scrape the loop, they read ADMIN_NAV — the thing both renderings actually depend on. That's strictly more meaningful: a test asserting data-section="workflow-settings-section" appears in the sidebar only ever proved one of the two navigations was right.

New test_admin_settings_nav_map.py rejects:

• a malformed map, or a tab/section appearing under two parents
• a tab with no pane, or a section pointing at no card
• a tab hardcoded back into the strip, which would reintroduce the drift
• Latest Features drifting off the end, or General losing the first slot

Verification

• Field names and card ids unchanged: 462 names, 110 card ids — saving untouched
• 75 functional test files: 33 → 32 failures (one fixed, none added)
• 20/20 admin templates parse under Jinja
• check_xss_sinks.py passes a full-file scan of every touched file
• node --check on the modified JS

Note on the interim grouping

The map currently has 12 groups, not the 14 in the target structure. Workflow and Data Lifecycle have no tabs yet, because their content still lives inside Workspaces and Safety — they appear in stage D when those cards move.

What this sets up

Stage D becomes a two-part edit per card: move the markup between partials, and move its entry between tabs in the map. The parity test fails if the two disagree, so a card can't silently lose its navigation entry — exactly the failure this PR just fixed by accident.

Version 0.260.010. Status doc updated at docs/explanation/features/ADMIN_SETTINGS_IA_REWORK_STATUS.md.