🚨 Bug: Notifications API (/api/v0/get-notifications) does not include PRIVATE_MESSAGE / NEW_MESSAGE transactions

## 🚨 Bug: Notifications API (`/api/v0/get-notifications`) does not include PRIVATE\_MESSAGE / NEW\_MESSAGE transactions

### **Summary**

The notifications API endpoint (`/api/v0/get-notifications`) does **not** return any notifications for **PRIVATE\_MESSAGE** or **NEW\_MESSAGE** transaction types. As a result, users do **not receive notifications when they get new messages**, and apps are unable to surface new-message alerts via notifications.

---

### **How to Reproduce**

1. **Send a PRIVATE\_MESSAGE or NEW\_MESSAGE transaction** to a user (e.g., using any DeSo messaging client).
2. Query the `/api/v0/get-notifications` endpoint for the recipient.
3. **Expected:** The API should return a notification for the new message (similar to how it does for other transaction types like follows, likes, transfers, etc).
4. **Actual:** **No notification is returned** for message transactions. The user receives the message, but there is no notification entry.

---

### **Reference / Context**

* These message transactions **are visible via** the `/api/v1/transaction-info` endpoint for the user, confirming the blockchain is registering them.
* However, the `/api/v0/get-notifications` API does **not include them**, so users and apps have no way to be notified of incoming messages through standard notification channels.
* Transaction types affected:

* `PRIVATE_MESSAGE`
* `NEW_MESSAGE`

---

### **Expected Behavior**

* **All incoming message transactions should generate notifications** in the `/api/v0/get-notifications` response, just like other social and financial events.
* This allows apps to notify users of new messages in real time and provides a unified notification experience.

---

### **Impact**

* **Users miss out on message notifications**—they only see messages if they manually check their inbox.
* Apps cannot provide real-time alerts or notifications for incoming messages.

---

### **Steps to Fix (Suggestion)**

* Update the backend notification logic to **generate notifications for PRIVATE\_MESSAGE and NEW\_MESSAGE transactions**.
* Include relevant message details (sender, timestamp, etc) in the notification payload so apps can surface meaningful message alerts.

---

### **Thank you!**

Let me know if you need example transactions, logs, or more details. Happy to provide any supporting info.

Start at the /api/v0/get-notifications endpoint and compare its handling with the /api/v1/transaction-info results for PRIVATE_MESSAGE and NEW_MESSAGE transactions. Trace the backend notification logic for these transaction types; done means incoming message transactions appear in the notifications response with meaningful sender and timestamp details.

Written by the indexing model from the issue text.