Public chat web app redirects anonymous visitors to console `/signin` (1.15.0)

### Self Checks

- [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542).
- [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general).
- [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones.
- [x] I confirm that I am using English to submit this report, otherwise it will be closed.
- [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
- [x] Please do not modify this template :) and fill in all the required fields.

### Dify version

dify-api / dify-web 1.15.0

### Cloud or Self Hosted

Self Hosted (Docker)

### Steps to reproduce

### Self Checks
- [x] I have searched for existing issues, including closed ones.
- [x] I confirm that I am using English to submit this report.

### Dify version
1.15.0 (both `langgenius/dify-api:1.15.0` and `langgenius/dify-web:1.15.0`)

### Cloud or Self Hosted
Self Hosted (Docker Compose)

### Steps to reproduce
1. Publish a Chatflow app and enable its Web App (`Overview` → `Web App` → `Enable`).
2. Copy the public URL, e.g. `https:///chat/`.
3. Open that URL in a browser that is **not** logged into the Dify console (a fresh incognito/private window works reliably).
4. The page briefly renders the chat UI, then automatically redirects to `/signin` (the console admin login page) within a couple of seconds.

Note: the same link opens and works normally in a browser that **is** currently logged into the Dify console. The bug only manifests for anonymous/guest visitors, which is the app's actual public-facing use case.

### ✔️ Expected Behavior
The published `/chat/{token}` web app should be fully usable by anonymous visitors without any Dify console session. This is the whole point of publishing a public web app.

### ❌ Actual Behavior
Anonymous visitors get bounced to the console `/signin` page shortly after the chat UI first renders.

### Diagnosis (from browser DevTools Network tab, in order of occurrence)
1. `GET /api/passport` → **200 OK** — returns a valid anonymous `access_token` (JWT) with `app_id`/`app_code` correctly matching the published app.
2. `GET /api/parameters` → **200 OK**
3. `GET /api/site` → **200 OK**
4. `GET /api/meta` → **200 OK**
5. `GET /console/api/account/profile` → **401 Unauthorized**
6. `POST /console/api/refresh-token` → **401 Unauthorized**
7. Frontend then performs a hard redirect to `/signin`.

The public/anonymous endpoints (passport, parameters, site, meta) all succeed and correctly issue a valid guest token. However, the `/chat/[token]` page also fires a call to the **console-only** endpoint `console/api/account/profile`. In previous versions this call returning 401 for an anonymous visitor was expected and silently ignored (see e.g. #7452, #31904 — other reports note this 401 "does not affect the final result"). In 1.15.0 this 401 instead appears to trigger the app's global unauthenticated-session handling, which calls `refresh-token`, fails again, and forces a redirect to the console login page — even on a route that should never require a console session.

Given that 1.15.0's release notes mention a redesigned landing/onboarding flow, this looks like a regression in that area: a global "is the user logged into console" check that should be scoped to console routes appears to now also run on public `/chat/` web app routes.

### Environment details
- Deployment: Docker Compose, self-hosted
- Reverse proxy / edge: Cloudflare Tunnel, custom domain (`https://`), console and web app served on the same hostname (no separate subdomain split between console and web app)
- Both `api` and `web` containers confirmed on the same `1.15.0` image tag (ruled out version skew)
- Confirmed not caused by:
- Stale browser cookies/localStorage (reproduces in a fresh incognito window)
- App-level Web App Access Control (this Community Edition build has no such setting exposed in the Web App settings dialog)
- CORS/domain misconfiguration (passport/parameters/site/meta all succeed from the same origin)
- Cloudflare edge caching of stale frontend assets (purged cache, same result)

### Additional context
Happy to provide HAR export of the Network trace or further logs if useful for reproduction.

### ✔️ Expected Behavior

create a working deployed page

### ❌ Actual Behavior

_No response_

Start at the public `/chat/[token]` entry point and trace the global unauthenticated-session handling around `/console/api/account/profile` and `/console/api/refresh-token`. Reproduce in a fresh private window, then verify that anonymous visitors can use the published chat without being redirected to `/signin`, while console authentication behavior remains intact.

Written by the indexing model from the issue text.