Please address the comments from this code review:

## Overall Comments
- Consider wrapping the `confirmService.confirm` call in `saveOidcConfig` in a try/catch so that any rejected promise (e.g., dialog failure or service error) is treated like a cancellation instead of potentially bubbling an unhandled rejection and leaving the UI in an inconsistent state.
- The OIDC configuration payload used in the Playwright tests is duplicated in multiple `fetch` calls; extracting a small helper to build this payload would reduce the risk of these falling out of sync with each other or with future config changes.

## Individual Comments

### Comment 1
<location path="docs/docs/configuration/account/index.mdx" line_range="153" />
<code_context>

 Linking an account is **optional**. By default, when no account is linked, **any user who can authenticate with your identity provider and has access to this app** is allowed to sign in. Your provider controls who has access — if a user can log in to the configured OIDC client, they are permitted into Cleanuparr.

+<Warning>
+The unlinked mode delegates **all** access decisions to your identity provider. This is appropriate for self-hosted providers where you control every account. It is **dangerous** with public providers open registration. Anyone who can sign up at that provider would be able to sign in to Cleanuparr as the administrator. If you use a public provider, link a specific account.
+</Warning>
+
</code_context>
<issue_to_address>
**nitpick (typo):** Fix wording in the warning about public providers with open registration

The phrase "It is **dangerous** with public providers open registration" is a bit ungrammatical. Consider rephrasing to "It is **dangerous** with public providers that allow open registration" or "It is **dangerous** when using public providers with open registration" to improve clarity while keeping the warning strong.

```suggestion
The unlinked mode delegates **all** access decisions to your identity provider. This is appropriate for self-hosted providers where you control every account. It is **dangerous** when using public providers with open registration. Anyone who can sign up at that provider would be able to sign in to Cleanuparr as the administrator. If you use a public provider, link a specific account.
```
</issue_to_address>

### Comment 2
<location path="e2e/tests/15-oidc-save-without-link-warning.spec.ts" line_range="13-38" />
<code_context>
+  test.beforeAll(async () => {
+    adminToken = await loginAndGetToken();
+    // Ensure OIDC is enabled (idempotent — no-op if already enabled).
+    await fetch(`${API}/api/account/oidc`, {
+      method: 'PUT',
+      headers: {
+        'Content-Type': 'application/json',
+        Authorization: `Bearer ${adminToken}`,
+      },
+      body: JSON.stringify({
+        enabled: true,
+        providerName: TEST_CONFIG.oidcProviderName,
+        issuerUrl: `${TEST_CONFIG.keycloakUrl}/realms/${TEST_CONFIG.realm}`,
+        clientId: TEST_CONFIG.clientId,
+        clientSecret: TEST_CONFIG.clientSecret,
+        scopes: 'openid profile email',
+        redirectUrl: '',
+        exclusiveMode: false,
+      }),
+    });
</code_context>
<issue_to_address>
**suggestion (testing):** Assert that setup API calls succeed so failures don’t surface later as opaque UI flakes

The `beforeAll` setup calls `fetch` for OIDC config and clearing linked subjects but ignores the responses. If these fail (e.g., misconfigured env or backend change), tests will run in an invalid state and only later UI checks will fail. Please assert `res.ok` (and throw with a clear error) for both the `PUT /api/account/oidc` and `DELETE /api/account/oidc/link` calls so setup failures are caught early and are easier to diagnose.

```suggestion
  test.beforeAll(async () => {
    adminToken = await loginAndGetToken();
    // Ensure OIDC is enabled (idempotent — no-op if already enabled).
    const oidcConfigResponse = await fetch(`${API}/api/account/oidc`, {
      method: 'PUT',
      headers: {
        'Content-Type': 'application/json',
        Authorization: `Bearer ${adminToken}`,
      },
      body: JSON.stringify({
        enabled: true,
        providerName: TEST_CONFIG.oidcProviderName,
        issuerUrl: `${TEST_CONFIG.keycloakUrl}/realms/${TEST_CONFIG.realm}`,
        clientId: TEST_CONFIG.clientId,
        clientSecret: TEST_CONFIG.clientSecret,
        scopes: 'openid profile email',
        redirectUrl: '',
        exclusiveMode: false,
      }),
    });

    if (!oidcConfigResponse.ok) {
      const body = await oidcConfigResponse
        .text()
        .catch(() => '<failed to read response body>');
      throw new Error(
        `Failed to configure OIDC in beforeAll (PUT /api/account/oidc): ` +
          `status=${oidcConfigResponse.status} ${oidcConfigResponse.statusText}, body=${body}`,
      );
    }

    // Clear any linked subject so the dangerous-state save warning is reachable.
    const clearLinkResponse = await fetch(`${API}/api/account/oidc/link`, {
      method: 'DELETE',
      headers: { Authorization: `Bearer ${adminToken}` },
    });

    if (!clearLinkResponse.ok) {
      const body = await clearLinkResponse
        .text()
        .catch(() => '<failed to read response body>');
      throw new Error(
        `Failed to clear linked OIDC subject in beforeAll (DELETE /api/account/oidc/link): ` +
          `status=${clearLinkResponse.status} ${clearLinkResponse.statusText}, body=${body}`,
      );
    }
  });
```
</issue_to_address>

### Comment 3
<location path="e2e/tests/15-oidc-save-without-link-warning.spec.ts" line_range="74" />
<code_context>
+
+    await page.getByRole('button', { name: 'Save OIDC Settings' }).click();
+
+    const dialog = page.getByRole('alertdialog');
+    await expect(dialog).toBeVisible({ timeout: 5_000 });
+    await expect(dialog).toContainText('Enable OIDC without a linked account');
+    await expect(dialog).toContainText('UNSAFE');
+    await expect(
+      dialog.getByRole('button', { name: 'Enable anyway' }),
</code_context>
<issue_to_address>
**suggestion (testing):** Make the dialog locator more specific to reduce ambiguity and future-proof the assertions

The dialog is currently located with `page.getByRole('alertdialog')` only. If another alert dialog is added (e.g., a different warning), these assertions could target the wrong element. To make the test more robust, scope the locator to this specific OIDC warning, for example:

```ts
const dialog = page.getByRole('alertdialog', {
  name: 'Enable OIDC without a linked account',
});
```

Since you already assert on this title, using it in the locator clarifies intent and reduces the risk of future false positives.

```suggestion
    const dialog = page.getByRole('alertdialog', {
      name: 'Enable OIDC without a linked account',
    });
```
</issue_to_address>