fix: add idempotency to prevent duplicate messages on network redelivery (#10)

[rafabd1]

Fix: Add idempotency to prevent duplicate messages on network redelivery

Closes #10

Problem

When I2P network conditions cause redelivery of the same message (a documented behavior of I2P's unreliable delivery semantics), the same message appears multiple times in the chat interface. This creates:

1. User confusion: Users see the same message repeated
2. Message clutter: Chat history becomes unreadable with duplicates
3. No detection mechanism: The application has no way to know if a message was already received

This is particularly problematic on unstable I2P connections during router bootstrapping or when tunnels degrade.

Solution

Implement message ID tracking for idempotency:

1. HashSet tracking:

   • Added received_message_ids: Mutex<HashSet<String>> to AppState
   • Tracks all message IDs that have been successfully processed
   • Uses HashSet for O(1) lookup performance

2. Duplicate detection in handle_incoming_message:

   • Before processing, check if message ID already exists in the set
   • If duplicate: skip silently (with debug logging)
   • If new: insert into set and process normally

3. Cleanup on session close:

   • When close_session is called, clear the received_message_ids set
   • Allows the same IDs to be used in new sessions
   • Prevents unbounded growth of the set across sessions

Security considerations

• Message IDs are UUIDs or similar unique identifiers (not sensitive)
• Tracking is in-memory only (never persisted to disk)
• Cleared on session close to prevent memory leaks

Implementation details

• Uses std::collections::HashSet for efficient duplicate detection
• Mutex protects concurrent access from receive loop and session close
• Duplicate messages are silently skipped (logged in debug builds for troubleshooting)
• Message ID tracking is scoped to the current session lifecycle