Fix lazy sql for v2/notifications

[ben851]

Summary | Résumé

We're seeing some traces on GET v2/notifications that are taking multiple seconds to complete like this one:
https://signoz.notification.prv/trace/f533fdf58d26e3c74df86c124746788a?spanId=6bd19d430592c75e&levelUp=0&levelDown=0

This particular request has over 500 sql queries. This PR will fix this so that it's only one sql query.

I've also scanned the code base to look for other potentially lazy sql queries and switched them to eager as well

Related Issues | Cartes liées

• API performance tuning

Test instructions | Instructions pour tester la modification

Verify functionality

Release Instructions | Instructions pour le déploiement

None.

Reviewer checklist | Liste de vérification du réviseur

• This PR does not break existing functionality.
• This PR does not violate GCNotify's privacy policies.
• This PR does not raise new security concerns. Refer to our GC Notify Risk Register document on our Google drive.
• This PR does not significantly alter performance.
• Additional required documentation resulting of these changes is covered (such as the README, setup instructions, a related ADR or the technical documentation).

⚠ If boxes cannot be checked off before merging the PR, they should be moved to the "Release Instructions" section with appropriate steps required to verify before release. For example, changes to celery code may require tests on staging to verify that performance has not been affected.

[Copilot]

Pull request overview

Reduces latency for GET v2/notifications by preventing an N+1 query pattern when serializing notifications that access scheduled_notification.

Changes:

• Eager-load Notification.scheduled_notification in get_notifications_for_service() via joinedload.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[andrewleith]

You added tests for the notifications_dao change but not the other two, should those also be added for completeness?

[andrewleith]

LGTM!