fix(frontend): reorder await api.me() before setUser in changePassword

En el fix anterior, await api.me() estaba DESPUES de setUser(u). Eso
significaba que React podria re-renderizar AuthenticatedApp entre el
setUser y el await, disparando el usePersistedState.load() que llama
api.getState() mientras la cookie todavia no estaba aplicada al
cookie store del browser. El await api.me() quedaba corriendo mientras
el 401 ya habia sido reportado.

Invertir el orden: await api.me() PRIMERO (confirma que la cookie
quedo realmente aplicada), despues setUser(u). Asi React re-renderiza
con la cookie ya activa para los fetches internos.

src/frontend/src/auth/AuthContext.tsx

@@ -53,12 +53,14 @@ export function AuthProvider({ children }: { children: ReactNode }) {
 
   const changePassword = useCallback(async (currentPassword: string, newPassword: string) => {
     const u = await api.changePassword(currentPassword, newPassword)
-    setUser(u)
-    // El Set-Cookie de la respuesta a veces no está visible para el fetch
-    // siguiente en el mismo microtask (Chrome/Firefox). Confirmamos con
-    // un round-trip al backend antes de soltar el control, asi React
-    // monta AuthenticatedApp con la cookie ya lista para los fetches internos.
+    // Round-trip ANTES de setUser(u). El Set-Cookie de la respuesta a
+    // change-password no está visible para el fetch siguiente en el mismo
+    // microtask en algunos navegadores. Si setteamos user primero, React
+    // re-renderiza AuthenticatedApp, su useEffect dispara api.getState() y
+    // pega el 401 antes de que el cookie esté aplicada al cookie store.
+    // Await api.me() ANTES fuerza ese round-trip a completarse.
     await api.me()
+    setUser(u)
   }, [])
 
   return (