[Issue]: Make a settings page for all three roles

[RenaudBernier]

Branch Name

feature/settings-page

Task

The sidebar footer links every role (user, coordinator, admin) to /settings, but app/(authenticated)/settings/page.tsx is a stub that only renders a "Settings" heading. There is currently nowhere in the app for someone to edit their own profile, change their password, or (outside the Overview page) sign out.

Build a real settings page that works for all three roles. It only ever reads and writes the signed-in user's own account — it is not an admin tool (admins already manage other users from the Users tab).

Sections:

• Profile — edit first name, last name, phone, address, gender, and date of birth. These columns are already declared on profiles in lib/db/schema.ts; confirm they exist in the database before building on them (see [Issue]: Schema: add personal/contact fields to user profiles #95). Signup stores first_name / last_name in the Supabase user metadata, so keep that in sync when the name changes.
• Account — show the email (read-only, it comes from auth.users) and the current role as a badge (reuse profileRoleLabel). Users cannot change their own role.
• Security — change password: current password, new password (min 8 characters, same rule as createUserAdminSchema), and confirmation. The current password must be verified server-side before the new one is set.
• Sign out — reuse the existing signout action from app/login/actions.ts.

Role-specific content (keep it light):

• user: links to Memberships (manage subscription) and Children.
• coordinator / admin: nothing extra for now.

Implementation notes:

• Server actions live in app/(authenticated)/settings/actions.ts, validate with zod, return the same { errors, message } shape as the other actions, and resolve the user id from the session — never from the form data.
• Follow the existing page pattern (Suspense + async content component, as in users/page.tsx and children/page.tsx) since the page reads auth cookies.
• Reuse existing UI pieces where possible (Card, Input, Select, DobField, sonner toasts).

Acceptance Criteria

• As a user, coordinator, or admin, opening /settings shows my own profile, email, and role
• I can update my first name, last name, phone, address, gender, and date of birth, and the changes persist after a reload
• Invalid input (empty name, future date of birth, etc.) shows field-level errors and nothing is saved
• I can change my password only after entering my correct current password; a wrong current password or mismatched confirmation shows an error
• I cannot change my role or another user's data from this page (the actions ignore any user id or role sent in the form data)
• I can sign out from the settings page
• As a user, I see links to Memberships and Children; coordinators and admins do not
• I made unit tests for the settings actions covering success, validation errors, and the unauthenticated case

Checklist

• I have checked for duplicate issues.
• I have assigned the issue to the correct project board.
• I have tagged the issue properly.

Code of Conduct

• I agree to follow this project's Code of Conduct