fix: add error handling in message receive loop (#9)

[rafabd1]

Fix: Add error handling in message receive loop

Closes #9

Problem

When the double ratchet decrypt operation fails (invalid MAC, wrong key, replay, etc.), the error is silently ignored in the receive loop. The loop continues processing subsequent messages despite being in an inconsistent state. This is a critical security and reliability gap because:

1. Security: Decryption failures could indicate tampering, replay attacks, or ratchet state corruption
2. Reliability: Continuing after decryption errors means the ratchet state may be desynchronized, causing all future messages to fail
3. User Experience: Users see messages appearing out of order or missing, with no indication of what went wrong

Solution

Treat decryption errors as fatal session-terminating events:

1. Immediate session closure: When handle_incoming_message returns an error, the receive loop now:

   • Emits a decryption_error event with a user-visible message
   • Clears the session state
   • Emits session_closed event
   • Breaks out of the receive loop

2. Enhanced error context:

   • Added debug logging of ratchet counter before decryption attempts
   • Error messages now include the counter value for debugging
   • Users see "Decryption failed: ratchet decrypt failed (counter=42): MAC verification failed" instead of silent failures

3. Security-first approach:

   • Decryption failures are treated as potential security incidents
   • Session termination prevents further processing in potentially corrupted state
   • Users must re-establish session to continue communication

Security considerations

• Decryption failures could indicate active attacks (replay, MITM)
• Terminating session prevents potential exploitation of ratchet state corruption
• No sensitive information is exposed in error messages (only counter values)

Implementation details

• Added #[cfg(debug_assertions)] logging for decryption attempts
• Error messages include ratchet counter for debugging but remain generic enough for users
• Session cleanup follows the same pattern as close_session command