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)
+    // Round-trip ANTES de setUser(u). El Set-Cookie de la respuesta a
-    // El Set-Cookie de la respuesta a veces no está visible para el fetch
+    // change-password no está visible para el fetch siguiente en el mismo
-    // siguiente en el mismo microtask (Chrome/Firefox). Confirmamos con
+    // microtask en algunos navegadores. Si setteamos user primero, React
-    // un round-trip al backend antes de soltar el control, asi React
+    // re-renderiza AuthenticatedApp, su useEffect dispara api.getState() y
-    // monta AuthenticatedApp con la cookie ya lista para los fetches internos.
+    // 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 (