QA summary for dashboard/settings password change flow

Verified:
- GET /settings unauthenticated -> 307 redirect to /sign-in?callbackURL=%2Fsettings
- GET /dashboard contains CTA href="/settings"
- Authenticated GET /settings renders currentPassword/newPassword/confirmPassword inputs
- POST /api/auth/change-password with wrong currentPassword -> 400 INVALID_PASSWORD
- Session remains valid after wrong currentPassword attempt
- POST /api/auth/change-password with valid currentPassword -> 200 OK
- Old password sign-in fails after change
- New password sign-in succeeds after change
- Second active session becomes unauthenticated after password rotation with revokeOtherSessions=true
- Accessing /settings with revoked session -> 307 redirect to sign-in

Environment note:
- Browser MCP could not run because Chrome was unavailable and could not be installed without sudo.
- Browser-level QA was replaced with HTTP/session-level verification plus runtime schema checks.
- Sign-in callback propagation verified after fix: POST /api/auth/sign-in/email with callbackURL=/settings returns {"url":"/settings"}