fix(web): fix infinite redirection while accessing console

[QuantumGhost]

Assisted-By: Codex:GPT-5.4

Important

1. Make sure you have read our contribution guidelines
2. Ensure there is an associated issue and you have been assigned to it
3. Use the correct syntax to link this PR: Fixes #<issue number>.

Summary

Closes #38457

Screenshots

Before	After
...	...

Checklist

• This change requires a documentation update, included: Dify Document
• I understand that this PR may be closed in case there was no previous discussion or issues. (This doesn't apply to typos!)
• I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
• I've updated the documentation accordingly.
• I ran make lint && make type-check (backend) and cd web && pnpm exec vp staged (frontend) to appease the lint gods

[QuantumGhost]

AI disclosure: This comment was drafted with Codex using GPT-5.4. I reviewed the explanation, and I am responsible for the content.

The reason for fixing this on the /signin probe instead of changing the backend auth endpoints is that the loop is caused by a client-side cache/redirect race.

/signin reuses the shared userProfile TanStack Query cache from the browser QueryClient. Because that cache can stay fresh for up to 5 minutes, the page can see stale successful profile data and immediately treat the session as logged in, which triggers router.replace('/') before the post-mount probe finishes.

After that redirect, the fresh probe catches up:

• /console/api/account/profile returns 401
• /console/api/refresh-token returns 401
• SSR for / redirects to /auth/refresh
• /auth/refresh sends the user back to /signin

That is what creates the repeated / -> /auth/refresh -> /signin -> / loop.

This patch breaks the loop in the narrowest place possible:

1. refetchOnMount: 'always' forces /signin to revalidate on mount instead of trusting cached profile data.
2. Redirecting away from /signin now requires a successful post-mount fetch (isFetchedAfterMount), so stale cache is treated as "still verifying" rather than "definitely logged in".

So the intent here is to preserve the existing backend contract and fix the incorrect client-side assumption that cached profile data is enough to prove the session is still valid.