Auth admin UI improvements

[markcrivera]

Problem Statement

The auth admin page works functionally but the UI needs improvement. From PR #183 review:

• Save bar is easy to miss. The bottom unsaved-changes bar has low visual weight (same background, no border emphasis) so it's not obvious that changes are pending. feat(auth)!: multi provider authentication system #183 (comment)
• No summary of what's being saved. The save bar approves/discards all pending changes at once with no indication of what changed, so a user can save without realizing a destructive change like a provider deletion is included. feat(auth)!: multi provider authentication system #183 (comment)
• No feedback when providers are added/removed. Adding or removing a provider produces no visible transition; in the worst case (e.g. ~20 unfilled LDAP/OAuth entries) it's hard to tell anything changed. feat(auth)!: multi provider authentication system #183 (comment)
• Provider list layout is flat and hard to scan. Providers are stacked in one long list separated by dividers identical to every other vertical divider on the page, so the list doesn't read as a distinct, navigable group, and it gets unwieldy once many providers are configured. feat(auth)!: multi provider authentication system #183 (comment)
• Group mappings use arbitrary role IDs entered as free text. Admins map provider groups to TIR roles by typing internal role IDs (e.g. 1, 2) into a freeform string, which isn't human-readable and isn't sourced from the DB. feat(auth)!: multi provider authentication system #183 (comment) feat(auth)!: multi provider authentication system #183 (comment)

Proposed Solution

Improve the auth admin page UI:

• Make the unsaved-changes save bar more noticeable (border color, background contrast, size) and accessible.
• Show a summary of pending changes before saving, highlighting destructive actions (e.g. provider deletions) so they can be reviewed in the same approve/deny step.
• Add an add/remove animation so it's clear when a provider is created or deleted.
• Rework the provider list into a cleaner, more scannable layout. Approach to be discussed, options include: distinct divider/section treatment so providers read as their own group; collapsible rows or collapsible cards per provider; or a sidebar selector that switches the active provider (similar to the admin sidebar).
• Replace the freeform group-mappings string with a structured editor: each row pairs a provider group with a TIR role chosen from a dropdown populated from the database (via the existing roles endpoint), shared across OIDC, OAuth, and LDAP. Provide an "advanced" toggle that exposes the raw formatted mapping string for users who prefer to edit it directly; the structured editor and the raw string stay in sync.
• For LDAP, when the connection fields are filled and a bind succeeds, prepopulate the group column with real groups discovered from the directory (extending the existing bind-test search). The discovered group identifier must match the form used during login-time group matching (DN vs CN).

Alternatives Considered

• Leave as-is, rejected: review feedback flags real clarity, accessibility, and usability gaps.
• Additional alternatives will be discussed.

Acceptance Criteria

• The unsaved-changes save bar is visually distinct (border/background/size) and meets accessibility expectations.
• Before saving, the user sees a human-readable summary of pending changes, with destructive changes highlighted.
• Adding or removing a provider shows a clear visual transition.
• Configured providers are presented in a cleaner, scannable layout that reads as a distinct group and stays usable with many providers (specific approach decided during discussion).
• Group mappings are edited as structured rows; the TIR role is selected from a DB-sourced dropdown (no hand-typed role IDs) for OIDC, OAuth, and LDAP.
• An "advanced" toggle lets users edit the raw formatted group-mapping string directly, kept in sync with the structured editor.
• For LDAP, with valid connection fields, the group column can be prepopulated with real directory groups, and the stored value matches what login-time group matching compares against.

Out of scope

• The same improvements on non-auth pages (auth-only for now).
• The "don't show again" delete-confirmation preference (tracked in "Don't show again" option on the delete-confirmation modal #193), related since a change summary at save time is what would let the delete confirmation be safely skipped.
• LDAP group prepopulation is not extended to OIDC/OAuth, whose groups are only known post-login from token claims.

Priority

Low — nice to have