Possible regression since v1.13.0: embedded chatbot reset keeps using old conversation_id

## Description

I found a possible regression in the embedded chatbot reset behavior.

In Dify v1.6.0, the built-in reset / new conversation button seemed to correctly start a new conversation. However, since around Dify v1.13.0, and still on v1.15.0, after clicking the built-in reset button in the embedded Web App chatbot, subsequent messages may still be sent with the old `conversation_id`.

The chat UI appears to be reset, but the actual conversation seems to remain the previous one.

I am not a frontend expert, so my analysis may be wrong. However, I wanted to report the behavior because it seems reproducible and may be related to the reset conversation logic.

## Environment

- Dify version: observed since around v1.13.0, still reproducible on v1.15.0
- Deployment: Self-hosted
- App type: Embedded Web App chatbot

## Steps to reproduce

1. Open an embedded Web App chatbot.
2. Send a message and confirm that a `conversation_id` is created.
3. Click the built-in reset / new conversation button.
4. Send another message.
5. Check the network request or localStorage.

## Expected behavior

After clicking the reset / new conversation button, the embedded chatbot should clear the current conversation state and start a new conversation. The next message should not be sent to the old `conversation_id`.

## Actual behavior

After clicking the reset button, the UI looks reset, but the old `conversation_id` may still be used for subsequent messages.

## Related issues / PRs

This looks related to previous conversation reset issues:

- #33362
- #34731
- #35489
- #35519

However, I can still reproduce a similar behavior in later versions.

## Possible cause

I am not sure if this is the root cause, but I found a possible dependency regression.

In v1.6.0, `handleNewConversation` included `handleChangeConversation` in its dependency array:

```ts
}, [handleChangeConversation, setShowNewConversationItemInList, handleNewConversationInputsChange, setClearChatList])
```

In v1.15.0, `handleNewConversation` still calls `handleChangeConversation('')`, but `handleChangeConversation` is no longer included in the dependency array:

```ts
}, [isTryApp, setShowNewConversationItemInList, handleNewConversationInputsChange, setClearChatList])
```

This may cause a stale closure and prevent the latest `handleChangeConversation` / `conversationIdInfo` update logic from being used when resetting the conversation.

Adding `handleChangeConversation` back to the dependency array may fix the issue:

```diff
- }, [isTryApp, setShowNewConversationItemInList, handleNewConversationInputsChange, setClearChatList])
+ }, [isTryApp, setShowNewConversationItemInList, handleChangeConversation, handleNewConversationInputsChange, setClearChatList])
```

I may be missing some context, but this dependency was present in v1.6.0 and seems to have been removed when the `isTryApp` branch was introduced. This may not be a new regression in v1.15.0 specifically, but rather a regression introduced around the Try Apps changes and still reproducible in later versions.

Locate handleNewConversation and handleChangeConversation in the embedded Web App chatbot, then compare their dependency handling with the v1.6.0 behavior described in the issue. Reproduce the reset flow and inspect the next network request or localStorage; done means the next message no longer uses the old conversation_id.

Written by the indexing model from the issue text.