feat(rbac): make Settings authorization permission-aware (#1738)

* feat(rbac): make Settings authorization permission-aware

Align Settings visibility and mutations with the existing permission matrix so Node Admin can edit node-scoped operational settings while system and credential surfaces stay Admin-protected.

* fix(rbac): tighten settings permission buckets and tests

Collapse settings key permission maps into one source of truth, and cover mixed PATCH atomicity plus image-update enabled writes.

* fix(rbac): tighten Settings scoped grants and CI assertions

Empty settings PATCH fails closed, node:manage is scoped to the active
node, system-only Settings stay hidden without system:settings, and
Check updates / webhooks mutate gates follow the permission matrix.

* fix(rbac): defer Settings section fallback until authz is ready

Keep deep links to permission-gated sections (e.g. license) intact while
can() is still fail-closed during permission metadata load.

* docs(settings): clarify Notifications channels vs routing authz

Channels use node:manage via /api/agents; routing and mute stay Admin-only.

docs/reference/settings.mdx

@@ -207,7 +207,7 @@ Create and manage user accounts with role-based access. The masthead publishes a
 | **Admin** | Community | Full access to all features |
 | **Viewer** | Community | Read-only access to stacks and nodes |
 | **Deployer** | Admiral | Can view stacks and trigger deployments |
-| **Node Admin** | Admiral | Full stack and node management, no system settings |
+| **Node Admin** | Admiral | Full stack and node management, including node-scoped operational Settings |
 | **Auditor** | Admiral | Read-only plus audit log access |
 
 See [RBAC & User Management](/features/rbac) for details on what each role can access.