fix(ssr): isolate Redux store per request and clean up SSR utilities

[blazeapps007]

Redux store SSR isolation — replaced the module-level singleton store with a makeStore factory. Providers now calls useState(() => makeStore()) so each server request renders with its own fresh store, preventing any user's auth state from leaking into another user's server-rendered HTML. On the client a single instance persists as before.
Type exports updated — AppStore, RootState, and AppDispatch are now derived from the factory's return type; all consumer files compile unchanged.
getCurrentTheme reads module store — removed the redundant localStorage.getItem call in favour of returning _theme directly, keeping a single source of truth in the module-level store.
Header comment — clarified the intentional no-op subscribe in useSyncExternalStore so future maintainers understand it is an SSR-safe initializer, not a live subscription.

[blazeapps007]

hi @ety001 when can you Review this one .

[ety001]

LGTM overall — the direction is correct and matches the official RTK + Next.js App Router pattern. Three non-blocking suggestions:

1. PR description slightly overstates the severity

The description says this prevents "any user's auth state from leaking into another user's server-rendered HTML." In the current codebase, every dispatch site is inside a client event handler (login/logout in use-auth.ts, onClick handlers, etc.) — there is no SSR-time dispatch today, so the module-level singleton was not actively leaking state between requests.

This change is still worth landing because it removes a footgun: the moment anyone adds server-side state hydration (e.g., dispatching setCredentials during render based on a request cookie), the singleton would silently turn into a cross-request leak. I'd suggest softening the wording to something like "future-proofs against per-request state leaking if we ever introduce server-side dispatch" so reviewers don't go hunting for an active bug.

2. Consider useRef instead of useState for the store

The official RTK Next.js App Router example uses:

const storeRef = useRef<AppStore | null>(null);
if (!storeRef.current) storeRef.current = makeStore();

useState(() => makeStore()) is functionally equivalent today, but useRef is the canonical pattern in the RTK docs and avoids any theoretical concern about React re-invoking a lazy initializer in future concurrent-rendering APIs. Not blocking — just a small alignment with the reference implementation.

3. Worth adding a tiny regression test

This PR converts a singleton to a factory, which is exactly the kind of architectural invariant a future contributor could quietly revert. The repo already has vitest.config.ts, so a 3-line test would lock it down:

import { makeStore } from '@/lib/store';

it('makeStore returns an isolated instance per call', () => {
  expect(makeStore()).not.toBe(makeStore());
});

Other observations (informational, no action requested)

• header.tsx subscribe function — () => () => {} allocates a new subscribe function on every render, so useSyncExternalStore re-subscribes each pass. Cleanup is a no-op so there's no functional impact, but hoisting it to a module-level const noopSubscribe = () => () => {}; would be slightly cleaner. This is pre-existing code; this PR only updated the comment.
• getCurrentTheme() semantic shift — the old implementation read localStorage on every call; the new one returns _theme. Since _theme is initialized from localStorage at module load and kept in sync via the storage event, this is correct for the documented use case. The only behavioral difference would be visible if something in the same tab mutated localStorage[THEME_KEY] outside of changeTheme, but no caller in the repo does that — getCurrentTheme actually has zero call sites today, so this is purely defensive cleanup.
• Consumer compatibility — confirmed by grepping src/: every consumer imports only RootState / AppDispatch as types (e.g., src/hooks/use-auth.ts, src/components/wallet/*-form.tsx, src/components/auth/login-form.tsx). No file imports the removed store singleton, so the rename is binary-compatible at the type level.

Happy to approve once (1) is addressed in the description; (2) and (3) are optional.