Even in this case, a loading solution works just fine, but it's the exact same pattern. You'd just `return <Spinner />` instead of `return null`. You also face the same issue, if you don't wait until post-mount.
Asynchronous state updates regardless if they come from UI events or data fetching should be handled the same on the rendering side in my mental model. This has nothing to do with SSR/SSG.
If one would just write client side rendered code as if the whole application was a SPA, then this problem never arises as long as there is a clear separation of concerns between GUI and state management.
A React component doesn't have to know where its data is coming from nor where it is rendered. Wrapping a component in a 'client only' higher order component seems to add unnecessary complexity and brittleness by complecting the rendering tree with side-effects and state management:
What if at some point there needs to be a different render of this component with data fetched during build time?
In my opinion the example illustrates how moving state management out of components (Redux and so on) is a more sane idea, compared to encapsulating local state and side effects into components.
The component in question should not render content during build time, it is a UI element that represents the login state, which you certainly do not want to have pre-rendered at all, let alone be indexed.