Modify conversation_id index options

[buvidk1234]

1. Modify conversation_id index options

Removed the unique constraint from the conversation_id index.

📝 Description

This PR fixes a critical regression introduced in #3668, where a global unique constraint was incorrectly added to the standalone conversation_id index in MongoDB.

Root Cause:
In OpenIM's architecture, a single conversation (e.g., a Single Chat or Group Chat) is shared among multiple users. Therefore, multiple documents in the conversation collection will naturally share the same conversation_id but have different owner_user_ids.
The unique constraint introduced in #3668 prevented the system from creating conversation records for the receiving user, throwing an E11000 duplicate key error.

Chain Reaction & Symptoms Fixed:

1. Server-side: Message sending succeeds, but conversation creation for the receiver fails due to the DB duplicate key error.
2. Client-side: Because the server fails to maintain the receiver's conversation record, client SDKs receive null or missing data during sync. This directly causes the frontend JS/Wasm SDK to crash with: [getAllConversationList] errCode: 10006, errMsg: Cannot convert undefined or null to object.

The Fix:
Removed .SetUnique(true) from the conversation_id index.

• The standalone index on conversation_id is kept as a normal index to prevent COLLSCAN (Out of Memory/Timeout issues like those in v3.8.3).
• Data integrity is already correctly enforced by the existing composite unique index on (owner_user_id, conversation_id).

⚠️ Important Note for Existing Deployments

For environments that have already run the faulty code, the conversation_id_1 index must be manually dropped from MongoDB (db.conversation.dropIndex("conversation_id_1")) before restarting the server, as the code change alone will not alter an existing MongoDB index's unique property.

🅰 Please add the issue ID after "Fixes #"

Fixes #3691 #3692 #3693 #3700 #3708

2. fix(msggateway): reset read deadline in pong handler to prevent Web client timeout

Root cause:
Due to browser API restrictions, Web (Wasm) clients cannot actively send standard WebSocket Ping frames. They rely entirely on server-initiated Pings (every 27s) and automatic browser Pong responses to maintain the connection. The pongHandler was empty and failed to reset the connection's read deadline upon receiving a Pong, causing the server's read loop to strictly time out at 30 seconds.

Solution:
Call c.setReadDeadline() inside the pongHandler to properly extend the connection's lifespan when a Pong frame is received.