feat: Resident Profile PR 4

[CK-7vn]

Pre-Submission PR Checklist

• No debug/console/fmt.Println statements
• Unnecessary development comments removed
• All acceptance criteria verified
• Functions according to ticket specifications
• Tested manually where applicable
• Branch rebased with latest main
• No business logic exists within the database layer

Description of the change

This is Resident Profile PR 4, this should be the last PR before the backend endpoints are implemented for the missing functionality.

Requirement rows implemented:
Rows 614-621 — Edit Profile (8 rows)

• 614: Edit Profile dialog opens from header button
• 615: Dialog contains First Name field, pre-populated
• 616: Dialog contains Last Name field, pre-populated
• 617: Dialog contains Username field, editable
• 618: Dialog contains Resident ID field, pre-populated
• 619: Save calls PATCH users/{id} with updated fields
• 620: Success toast appears after save
• 621: Page data refreshes after successful edit (SWR mutate)

Rows 622-628 — Reset Password (7 rows)

• 622: Reset Password button opens confirmation dialog
• 623: Confirmation dialog explains what will happen
• 624: Cancel button closes without action
• 625: Confirm calls POST users/{id}/student-password
• 626: Result phase shows temp password in monospace
• 627: Copy button copies to clipboard with "Copied!" feedback (2s)
• 628: Done button closes dialog

Rows 629-637 — Deactivate (9 rows)

• 629: Deactivate option in dropdown opens dialog
• 630: Dialog shows impact bullet: withdrawn from all classes/programs
• 631: Dialog shows impact bullet: account locked and marked Deactivated
• 632: Dialog shows impact bullet: staff can no longer edit account
• 633: Dialog shows impact bullet: resident cannot log in or enroll
• 634: Dialog shows impact bullet: deactivation time recorded
• 635: Dialog shows impact bullet: history/favorites preserved and searchable
• 636: Orange confirmation box requires exact Resident ID match
• 637: Button disabled until ID matches, success toast on confirm

Rows 638-648 — Transfer (11 rows)

• 638: Transfer option visible for DeptAdmin and SuperAdmin
• 639: Dialog opens with current facility displayed
• 640: Facility dropdown loads from API, excludes current facility
• 641: Selecting facility triggers verify endpoint
• 642: Program conflicts displayed from verify response
• 643: Orange impact warning about unenrollment shown
• 644: "What happens next" section with preserved history/login info
• 645: ID confirmation input required
• 646: Transfer button disabled until facility selected, verified, and ID matches
• 647: Calls PATCH users/resident-transfer with correct payload
• 648: Success toast, page data refreshes

Rows 649-655 — Delete (7 rows)

• 649: Delete option in dropdown opens dialog
• 650: Red warning about permanent, irreversible deletion
• 651: Red confirmation box requires exact Resident ID
• 652: Delete button disabled until ID matches
• 653: Calls DELETE users/{id}
• 654: Success toast appears
• 655: Navigates to /residents after deletion

Screenshot(s)

This PR

Redesign

Additional context

Areas to focus on during review:

• Transfer dialog is the most complex — verify the facility select -> verify ->
  conflicts flow
• All dialogs reset their internal state (confirmation inputs, form fields) when closed
• Error handling: all dialogs catch API failures and show toast.error(resp.message)

Known items not addressed in this PR:

• Historical Notes "Add Note" callback remains a no-op (not part of rows 614-655)
• Backend deferred items (schedule field on ResidentProgramOverview, weekly attendance
  trend endpoint) tracked separately
• Note that the Username field is not editable even though it is in the redesign because our backend rejects username changes currently, and I don't quite see a reason to change that, I don't foresee admins wanting to be bogged down by username change requests.