feat(settings): granular per-subpage permissions and grouped permissions UI

[larsgeorge-db]

Summary

Refactors the Settings permission model from a single Admin-only flag into a two-level scheme and groups permissions in the Role editor for easier navigation. Closes #427.

Permission model

• Layout gate: top-level settings permission (None / Read-only / Read/Write / Admin) controls access to /settings and its sidebar.
• Per-subpage: every Settings subpage now has its own dedicated settings-<name> permission (None / RO / RW / Admin):
  • settings-general, settings-roles, settings-git, settings-ui, settings-tags, settings-connectors, settings-mcp, settings-jobs, settings-search, settings-delivery, settings-semantic-models, settings-certification-levels, settings-data-domains, settings-business-roles, settings-delivery-methods, settings-asset-types, settings-teams, settings-projects, settings-audit, settings-workflows.
• Access to a subpage requires both the layout gate AND the per-subpage permission.

Grouped permissions UI

The Role editor now groups feature permissions into Discover / Build / Govern / Deploy / Settings / Other, mirroring the main sidebar. Each feature carries a new group field exposed from SettingsManager.get_features_with_access_levels.

Migration

An idempotent startup seeder (SettingsManager.upgrade_admin_role_for_new_features) grants the built-in Admin role Admin on every new settings-* ID, so existing deployments work without manual reconfiguration.

Backend route updates

• settings_routes.py: added per-subpage PermissionChecker to general/roles/search/git/delivery routes.
• workflows_routes.py, approvals_routes.py: switched from generic settings to settings-workflows.
• certification_levels_routes.py, connection_routes.py, mcp_tokens_routes.py: switched to their respective settings-* IDs.
• Reference-data routes (data-domains, teams, etc.) keep their existing IDs — the new settings-* IDs are UI-only gates per the chosen approach in the PRD.

Frontend

• SettingsLayout filters the sidebar by per-subpage permission and redirects to / if the user lacks settings Read-only.
• SettingsPageWrapper accepts a new required permissionId prop and AND-gates with the layout permission.
• Both components now correctly wait for the permissions store to finish initializing (_initAttempted / _isInitializing) before deciding to redirect, fixing a race where the layout would bounce to / on first mount.
• User menu hides the Settings link if the user lacks settings Read-only.
• i18n keys added for the six group headers in all 7 supported locales.

Test plan

• Backend unit tests pass (test_settings_manager.py: 24/25 — one pre-existing unrelated failure).
• Frontend tsc --noEmit clean.
• Playwright verified:
  • /settings loads and auto-redirects to /settings/general for Admin user.
  • All sidebar groups render (Reference Data, Configuration, Integrations, Operations, Access Control).
  • /settings/roles loads with all 6 default roles.
  • Role edit dialog → Permissions tab shows all 6 groups in correct order: Discover, Build, Govern, Deploy, Settings, Other.
• Manual: verify a non-Admin role with only settings-general Read-only sees just the General item in the sidebar and is denied for other subpages.
• Manual: verify a user with settings: None is redirected from /settings to /.