docs: v1 docs refresh (batch 8) (#1797)

* docs(rbac): refresh Users panel screenshots to current build

Recapture users-list, add-user-form, role-selector, and delete-confirm
against the live app so they reflect the current Community RBAC parity
UI. Update alt text to match.

* docs(sso): refresh SSO settings screenshots and document last-provider lockout guard

Screenshots were captured against a stale build; refresh with current UI.
Also documents the guard that blocks disabling or removing the last
enabled SSO provider while SSO-only mode is active, and corrects the
Recovery settings path (Operations, not System).

* docs(sso): refresh SSO quickstart screenshots to current build

Screenshots were captured against a stale build; recapture the provider
overview and the LDAP test-connection failure state against current UI.
Page text already matched the implementation, so no content changes.

* docs(alerts): refresh Alerts and Notifications for current RBAC and retention behavior

Verified every claim against current backend/frontend code and the live app.
Corrected two factual errors: stack alert rule add/delete visibility now
follows the stack:edit permission (roles renamed since the last refresh,
not an admin-only gate), and the notification_history cap is a 500-row
per-stack / 1000-row per-node-unattached pair enforced on the monitor's
30-second cleanup pass, not a flat 100-row per-node cap evicted on insert.

Added the stack_taken_down category (also part of the built-in bell
quieting rule, previously undocumented) and the seven history-only
categories that are filterable but never dispatched externally. Noted the
two vulnerability-scan retention controls now sharing the Data Retention
page, with a cross-link to their own doc.

Recaptured all eight screenshots against the production node.

* docs(fleet-sync): remove stale Admiral gate claim, refresh replica screenshots

Fleet Sync's replication, anchor, and demote mechanics have been free on
Community since the paid gates were dropped from sync-status and
reset-anchor; the Prerequisites table still claimed the control instance
needed Admiral. Also documents the one-click "Reset anchor on peer"
recovery banner on Settings -> Nodes, verified live against a real
control/replica pair, and replaces all four screenshots with current
captures.

docs/features/sso.mdx

@@ -87,6 +87,12 @@ At the top of the page, **Authentication mode** chooses how interactive login wo
 
 SSO only cannot be enabled until at least one provider is enabled, a connection test succeeds, and the signed-in administrator authenticated through SSO with the Admin role. Confirm the outage-risk warning before saving. Existing sessions stay valid until they expire or are revoked.
 
+<Frame>
+  <img src="/images/sso/sso-settings-sso-only-confirm.png" alt="SSO-only confirmation panel showing the outage-risk warning, the list of providers that remain available, the emergency recovery command, and the confirmation checkbox required before saving" />
+</Frame>
+
+Once SSO only is active, you cannot disable or remove the last enabled provider from the Settings UI; doing so would lock out every SSO user with no way to sign in. Switch back to **Local and SSO** first, or use the emergency recovery CLI below, before disabling or removing that provider.
+
 If the identity provider is unavailable after SSO only is enabled, restore local password login from the host:
 
 ```bash
@@ -94,7 +100,7 @@ docker compose exec sencho node dist/cli/enableLocalLogin.js
 docker compose restart sencho
 ```
 
-Restart is required so the running process reloads the setting. The same command is listed under **Settings → System → Recovery**.
+Restart is required so the running process reloads the setting. The same command is listed under **Settings → Operations → Recovery**.
 
 <Frame>
   <img src="/images/sso/sso-settings.png" alt="SSO settings panel listing the five identity providers as collapsible cards with enable / disable toggles" />
@@ -318,7 +324,7 @@ If not set, Sencho auto-detects the URL from the request's `Host` header and pro
   </Accordion>
 
   <Accordion title="Users land with the wrong username or no email">
-    Enable **Developer Mode** (Settings → Operations → Developer Diagnostics) to log the raw claims Sencho receives from the provider in the server logs. Check your provider's documentation for which claims it includes in the ID token and `userinfo` response, and verify that the configured **Scopes** include everything your provider needs to emit `email` and group claims. For Custom OIDC, override **User ID Claim**, **Username Claim**, or **Email Claim** to match the names your provider actually emits.
+    Enable **Developer mode** (Settings → Operations → Developer Diagnostics) to log the raw claims Sencho receives from the provider in the server logs. Check your provider's documentation for which claims it includes in the ID token and `userinfo` response, and verify that the configured **Scopes** include everything your provider needs to emit `email` and group claims. For Custom OIDC, override **User ID Claim**, **Username Claim**, or **Email Claim** to match the names your provider actually emits.
   </Accordion>
 
   <Accordion title="The provider returns 'invalid redirect URI' during sign-in">
@@ -338,6 +344,10 @@ If not set, Sencho auto-detects the URL from the request's `Host` header and pro
 
     Then sign in with a local administrator account and repair the identity provider configuration before enabling SSO only again.
   </Accordion>
+
+  <Accordion title="'Cannot disable/delete the last SSO provider while SSO-only mode is active'">
+    Sencho blocks this to prevent a lockout: with SSO only active and no local password fallback, disabling or removing the one remaining enabled provider would leave nobody able to sign in. Switch **Authentication mode** back to **Local and SSO** first, then disable or remove the provider, or re-enable it under a different configuration if you are migrating identity providers.
+  </Accordion>
 </AccordionGroup>
 
 The [operations troubleshooting page](/operations/troubleshooting#ldap-connection-refused) covers a few more cases that come up during initial setup, including LDAP connection refused, TLS certificate errors, and OAuth callback URL mismatches.