[Feature]: Settings permissions — split sub-menus into separate permissions; add READ/WRITE to root

Reported by external stakeholder (codename: dtag) — 2026-05-20

Is there an existing issue for this?

• I have searched the existing issues

Problem statement

The Settings feature currently exposes a single permission scope. As a result, granting a user any meaningful Settings access either lets them into the whole Settings surface or keeps them out entirely. There is no way to express "this user may view Settings and edit only reference data, but must not touch RBAC".

Proposed Solution

Two coordinated changes:

1. Split each Settings sub-menu into its own permission scope, e.g.:
   • settings.connection
   • settings.rbac (Roles, Personas, Permissions)
   • settings.jobs
   • settings.git
   • settings.reference-data
   • settings.integrations
   • (others as enumerated by the Settings view)
2. Add a READ / READ_WRITE capability to the Settings root so that a user can be granted entry to the Settings view without implicitly being granted any sub-menu capabilities. Sub-menu capabilities then gate each individual section.

The persona/role editor should expose these new capabilities as toggles.

Additional Context

This is the prerequisite for cleanly separating concerns between "Settings administrators" (full control) and "Settings operators" (e.g. reference-data editors). It is also the structural fix that the companion bug ([BUG]: settings:ADMIN implicitly grants admin-level capabilities) depends on.

Start by tracing the Settings view and the persona/role editor, then enumerate every Settings sub-menu that needs its own permission scope. Done means the root exposes READ and READ_WRITE capabilities, each sub-menu is independently gated, and the new capabilities appear as editor toggles without granting unrelated access.