Improve DM Handshake UI and Queue Reliability

[callebtc]

Summary

This PR improves the responsiveness and reliability of private messaging during the Noise session establishment phase.

Key Changes

• Animated Handshake Feedback: Replaced the static "refresh" icon with an animated "..." text indicator in the chat header while a handshake is in progress.
• Thread-Safe DM Queue: Refactored MessageRouter to use ConcurrentHashMap and synchronized lists, ensuring safe concurrent access between the UI and background services.
• Immediate Delivery: Implemented instant message flushing upon handshake completion. Messages no longer wait for the 1-second polling cycle.
• Direct UI Updates: Added an onSessionEstablished callback to the mesh delegate to allow the UI to transition immediately from "handshaking" to "secure" state.

Verification Results

• Verified that messages sent before a session is established are correctly queued and delivered immediately upon handshake.
• Confirmed the UI remains responsive and the animated indicator works as expected.
• Verified that thread-safety improvements prevent potential race conditions in the MessageRouter outbox.

Reviewer Recommendations

• Focus on the MessageRouter.kt changes for thread-safety.
• Check the integration of the new onSessionEstablished delegate method in ChatViewModel and MeshDelegateHandler.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f26f423c14

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Avoid non-atomic getOrPut on ConcurrentHashMap

Because outbox is now a ConcurrentHashMap, getOrPut is no longer atomic. If two threads queue a message for the same peerID concurrently and the key is absent, both can create separate lists and one put will overwrite the other; the messages added to the losing list are no longer reachable and will never flush. This regression only appears under concurrent sends (e.g., UI and background threads) and defeats the “thread-safe” change. Use computeIfAbsent or synchronize around creation to guarantee a single list per peer.

Useful? React with 👍 / 👎.