Keep stored tokens on transient errors during profile fetch

[paskal]

Previously, getProfileFetch removed both jwt and refreshToken from localStorage on any failure, including network errors and 5xx while the backend was briefly unreachable at startup, permanently logging the user out.

After this change tokens are cleared only when the server explicitly rejects the credentials:

• a 401 on the profile followed by a refused refresh token, or
• a 401 on the retry with a freshly refreshed token.

Transient refresh failures (network error, 5xx, 408, 429 from /refresh) keep the tokens so the next launch can retry with the same session. A non-401 profile error (e.g. 403/404) also keeps the tokens, since it does not indicate the stored credentials are invalid. The expired-token 401 is deliberately not forwarded to errorFromServer on the transient path, since it would trigger a logOut that wipes the very tokens being preserved.

Adds tests, including one that executes nested thunks to prove no LOGOUT is dispatched on a transient refresh failure.

Note: the socket TOKEN_EXPIRED path in store.ts has the same transient-wipe behaviour and is left for a separate change.

[vercel]

@paskal is attempting to deploy a commit to the ksinon-5464's projects Team on Vercel.

A member of the Team first needs to authorize it.

[paskal]

The one failing check here is the Vercel commit status ("Authorization required to deploy"). That is Vercel's fork-PR gate: deploying a commit from an external fork needs a member of the Vercel team to authorise it, so it cannot be cleared from this branch — no code or config change on the PR affects it.

The Netlify deploy-preview, which actually builds the app, passes. eslint, tsc --noEmit, the Jest suite and npm run build are all green locally.