Stale conversation_id still causes infinite 404 loop on v1.17.1; 1.17.0's ENABLE_CONVERSATION_CLEANUP_TASK makes it more frequent

### 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

v1.17.1 (verified in source; also confirmed unfixed in v1.15.0 – v1.17.0)

### Cloud or Self Hosted

Self Hosted (Docker)

### Steps to reproduce

1. Deploy a Chatflow app and share it as a Web App via the `/chatbot/` embed URL.
2. Open the chatbot and send a message — the `conversation_id` is persisted client-side (`conversationIdInfo` in localStorage, scoped via `useConversationSelection`).
3. Make that `conversation_id` stale on the server — delete it from the console, or (new in 1.17.0) let `ENABLE_CONVERSATION_CLEANUP_TASK` auto-clean it.
4. Reload the chatbot page.

nginx access log (identifiers redacted):

```
"GET /api/messages?conversation_id=xxxxx&limit=20&first_id= HTTP/1.1" 404 201
"GET /api/messages?conversation_id=xxxxx&limit=20&first_id= HTTP/1.1" 404 201
"GET /api/messages?conversation_id=xxxxx&limit=20&first_id= HTTP/1.1" 404 201
... (repeats every ~2-3 seconds)
```

### ✔️ Expected Behavior

The frontend detects the 404, clears the stale conversation id, and automatically falls back to a fresh conversation.

### ❌ Actual Behavior

`useShareChatList` keeps retrying the stale id (default retries plus refetch-on-window-focus) and the error state is never consumed by the chat hooks, so the page is trapped in an infinite 404 loop. The only workaround is manually clearing browser site data.

### Additional context

- Original report: #39484 (still open). Earlier history: #34731 was closed with its fix never landing in a release; #34945 went stale with merge conflicts.
- **A conflict-free, fully tested fix is ready for review in #39593** — rebased onto latest `main` (adapted to the new `useConversationSelection` storage layer and the environment-address 404 protocol; all existing and new vitest cases pass).
- New aggravator in 1.17.0: `ENABLE_CONVERSATION_CLEANUP_TASK` deletes old conversations server-side on a schedule, so clients still holding those ids now hit this loop systematically — the missing client-side recovery matters more in 1.17.x than when the issue was first reported.
- Verified in the v1.17.1 source: none of the three fix points are present (404-aware retry in `useShareChatList`; error consumption in the `embedded-chatbot` / `chat-with-history` hooks; stale-id cleanup).

Start with the existing fix in issue #39593 and inspect the named useShareChatList, embedded-chatbot, and chat-with-history hooks, along with their vitest cases. The work is complete when a stale conversation_id no longer produces repeated 404 requests and the chatbot falls back to a fresh conversation, with all existing and new tests passing.

Written by the indexing model from the issue text.