The menu and the page do not agree about who is logged in. `App.tsx` keeps `isLoggedIn` in `useState(false)` and passes it to the navbar and to `ProtectedRoute`, while the "Your gymnasts" page asks the server (`me`). Two things follow: - After a reload the session is restored (`restoreSession`), but `useState` starts as `false`, so `ProtectedRoute` sends a logged-in coach away from `/gymnasts`. - The navbar button only flips the local value. The menu can say "Log out" while the page says "Log in to see your gymnasts". There is also no login page, so "Log in" in the navbar leads nowhere. Peer feedback asked for one source of login state and a clear path from login to creating and seeing your own data. ### What to do - One source of truth: a small `Me` query behind an `AuthProvider` and a `useAuth()` hook (`loading`, `authenticated`, `anonymous`, and the coach). The navbar, `ProtectedRoute` and the gymnasts page all read it. Remove `isLoggedIn` from `App.tsx`. - `ProtectedRoute` waits while the status is `loading` (no redirect before the session is restored), and sends an anonymous visitor to `/login`, remembering where they wanted to go. - A `/login` page. The navbar "Log in" links to it, "Log out" ends the session. After logging in the visitor goes back to where they were. - `login`, `devLogin` and `logout` reset the Apollo store (`resetStore`), so active queries (the menu, the page) refetch at once. ### Done when - [ ] The navbar, `ProtectedRoute` and the gymnasts page read the same `useAuth()`. - [ ] Reloading `/gymnasts` while logged in stays on `/gymnasts`. - [ ] "Log in" goes to `/login`, and after logging in the visitor lands where they were going. - [ ] A test covers the whole flow: log in, create a gymnast, reload, log out, log in again, and the gymnast is still there. - [ ] The behaviour is described in `docs/UI_PLANS.md` and `docs/API.md`.