Fix growing unread notification counts by unifying key generation logic

[OptimoSupreme]

Fixes #109

I discovered a bug with the notification count persistence where src/service/pusher/append.rs was manually constructing database keys using raw bytes (concatenating user ID, separator, and room ID), whereas the reset_notification_counts logic in notification.rs uses a structured tuple key (UserId, RoomId).

This mismatch meant that increment and reset were operating on different database keys. As a result, new notifications would increment a counter that the reset logic never touched, causing unread counts to grow indefinitely without ever being cleared. This PR refactors append.rs to use the same (UserId, RoomId) tuple key structure and updates the increment logic to use the async database API, ensuring that increments and resets target the same entry.

Validations:
Verified that the code compiles correctly with cargo check.
Confirmed key structure matches notification.rs.

[jevolk]

Thank you so much for looking into this. I am currently out of the office this week so this probably won't percolate up into main branch until I get back. This looks like amazing work so I am just giving you the heads up so you're not left wondering about what is going on. Again thank you 🙏🏻

[OptimoSupreme]

For sure! Just a heads up I believe that the database keys mismatch is the culprit here, and I am hopeful that this will resolve the issue. To be completely straight forward though I have not had a chance to actually test it. I'm unsure as of now if we will need to implement some sort of one time key reset or if it will just work. If I get a chance I will build a docker image, but I didn't want to you merge to main without testing it out.