feat(ui-react): add admin user management pages

[luizhf42]

What

Admin user list and detail pages for the React UI, covering CRUD operations, search, pagination, login-as-user impersonation, and SAML password reset.

Why

Implements features 3 and 4 from the admin panel roadmap (shellhub-io/team#93): User Administration and User Password Reset. The admin sidebar already links to /admin/users but the pages didn't exist yet.

Changes

• hooks/useAdminUsers: Paginated list query with base64-encoded username search filter, single-user detail query. Both are admin-gated and skip 401 retries.
• hooks/useAdminUserMutations: Create, update, delete, and reset-password mutations. All invalidate relevant TanStack Query cache keys on success — reset-password invalidates both list and detail caches so the "Set Password" button disappears after enabling local auth on a SAML-only user.
• api/errors: Added isSdkErrorWithBody type guard to replace unsafe double-casts (err as unknown as { body: string[] }) when handling 400/409 responses with field-level error arrays.
• pages/admin/users/index: User list with debounced server-side search, row-click navigation to detail, inline edit/delete/login-as actions. Login-as opens an impersonation token URL in a new tab.
• pages/admin/users/UserDetails: Two-column info grid (identity + account), breadcrumb nav, edit drawer, delete confirmation, and a "Set Password" button (visible only for SAML-only users). Uses type UserDetail = GetUserResponse & { admin?: boolean } to work around the admin field being absent from the OpenAPI spec for the detail endpoint.
• pages/admin/users/CreateUserDrawer, EditUserDrawer: Form drawers with namespace limit controls (enable → disable creation or set max), password visibility toggle, confirmed/admin checkboxes. Edit drawer prevents self-demotion and un-confirming already-confirmed users.
• pages/admin/users/ResetPasswordDialog: Two-step dialog — confirm intent, then display generated password with copy button. Differentiates 400 ("already has local password") from generic errors.
• App.tsx: Registered /admin/users and /admin/users/:id routes inside AdminRoute > LicenseGuard.

Testing

1016 tests passing (162 new). Coverage includes hook behavior (query guards, cache invalidation, filter encoding), type guard edge cases, and component interaction flows (form submission, error states, state reset on reopen, accessibility attributes).

[github-actions]

Claude finished @luizhf42's task in 3m 19s —— View job

---

Code Review Complete

Reviewed 17 files across code quality, security, testing, TypeScript/React patterns, and architecture. 1 inline issue posted (high severity).

Additional notes

• The ConfirmDialog convention (consumers must catch their own errors) is also violated in UserDetails.tsx:314-319 with the same delete pattern — noted in the inline comment.
• The type UserDetail = GetUserResponse & { admin?: boolean } workaround in UserDetails.tsx:24 exists because the OpenAPI spec for GET /admin/api/users/{id} doesn't include the admin field in its response schema, even though the Go backend returns it. Consider updating the spec to include admin so the generated client type is correct and the cast can be removed.
• The handleLoginAs catch blocks in both index.tsx:76-78 and UserDetails.tsx:90-92 silently discard token-fetch errors. While the comment says "admin can retry", the admin has no signal that a retry is needed. Consider adding transient error feedback.

---

If you've addressed the feedback and want a new review, tag @shellhub-io/admin and a team member can trigger it.

[luizhf42]

OpenAPI spec gap for the missing admin field tracked in #6088.

[gustavosbarreto]

/review

[github-actions]

Claude finished @gustavosbarreto's task in 50s —— View job

---

Code Review Complete

Reviewed 17 files across code quality, security, testing, TypeScript/React patterns, and architecture. 2 inline issues posted (2 medium).

Additional notes

• The ConfirmDialog convention (consumers must catch their own errors) is also violated in UserDetails.tsx:318-345 with the same delete pattern — deleteError is component-level state that is never reset between dialog re-opens, though this is less impactful since there is only one user on the detail page.
• The type UserDetail = GetUserResponse & { admin?: boolean } workaround in UserDetails.tsx:24 was already tracked in fix(openapi): add missing fields to admin user endpoints #6088.
• useDeleteUser invalidates both "getUsers" and "getUser" on success. When deleting from UserDetails, this triggers a background refetch for the just-deleted user (404) before the navigation away completes. Consider removing "getUser" from the delete hook's invalidation list — there is no reason to refresh a query for a deleted resource.

---

If you've addressed the feedback and want a new review, tag @shellhub-io/admin and a team member can trigger it.

[otavio]

/review

[github-actions]

Claude finished @otavio's task in 6m 3s —— View job

---

Code Review Complete

Reviewed 17 files across code quality, security, testing, TypeScript/React patterns, and architecture — no issues found. The code looks good as-is.

Additional notes

• The previous review feedback (stale deleteError, silent delete/login-as errors) has been addressed in follow-up commits.
• The type UserDetail = GetUserResponse & { admin?: boolean } workaround and status field gap remain tracked in fix(openapi): add missing fields to admin user endpoints #6088.
• useDeleteUser still invalidates "getUser" on success (noted in the last review), which triggers a harmless 404 refetch for the deleted resource — a minor optimization opportunity but not a bug.

---

If you've addressed the feedback and want a new review, tag @shellhub-io/admin and a team member can trigger it.

[gustavosbarreto]

/review

[github-actions]

Claude finished @gustavosbarreto's task in 19m 2s —— View job

---

Code Review Complete

Reviewed 24 files across code quality, security, testing, TypeScript/React patterns, and architecture — no issues found. The code looks good as-is.

Additional notes

• The userAdminResponse OpenAPI schema (list endpoint) does not include max_namespaces, even though the Go backend serializes it via models.User. The generated TypeScript type therefore omits it. When EditUserDrawer receives a UserAdminResponse from the list page, user.max_namespaces is undefined at the type level — though it's present at runtime because the SDK passes through untyped JSON fields. Consider adding max_namespaces to userAdminResponse.yaml so the type contract matches reality and future SDK changes (e.g., strict deserialization) don't break the edit flow.
• The useDeleteUser hook still invalidates "getUser" on success (noted in a prior review round), which triggers a harmless 404 refetch for the just-deleted resource — minor optimization opportunity.
• The OpenAPI spec corrections (confirmed → status, pending → not-confirmed, added admin field) are well-aligned with the existing backend models and migration_75.

---

If you've addressed the feedback and want a new review, tag @shellhub-io/admin and a team member can trigger it.