feat: dashboard alert filters (involvement, team, service)

[NisargPipaliya]

Summary

• /alerts and /teams OpenAPI endpoints + schemas for dashboard filtering
• alerts_repo / alerts_view involvement filtering support
• Dashboard UI (filters panel), overview CSS and i18n
• Tests for the involvement filter and teams API

Testing

• Added Test cased for the filter api and checked the working.

Issue: #123

[NisargPipaliya]

/sign-cla

[Aidaho12]

Thanks for the contribution! The filtering functionality is useful, especially the ability to focus on alerts where the current user is involved.

However, I think the current implementation needs some UX improvements and a technical fix before merging.

1. Simplify the Dashboard UX

The Dashboard already contains multiple summary cards, charts, active alerts, service impact, and recent activity.

Adding a permanently visible filter card at the top makes the interface more crowded and pushes important operational information further down the page.

I'd suggest the following changes:

• Move the filters into the Active Alerts section instead of adding a separate Dashboard-wide filter card.
• Add a compact My Alerts / All Alerts switch for quick access to relevant alerts.
• Put advanced filters (Involvement and Service) behind a collapsible Filters control.
• Reuse the existing global Team selector rather than introducing a second Team filter on the Dashboard.
• Keep global KPIs, System Status, Service Health, and other overview widgets independent of personal alert filters. Selecting "My Alerts" should not make the overall system appear healthy when other teams still have active incidents.
• Preserve the selected filters when navigating from Active Alerts to the full Alerts page.
• Ensure the layout remains compact and usable on mobile devices.

The goal is to keep the Dashboard focused on providing a quick operational overview, while allowing users to narrow down their personal workload when needed.

2. Fix the AlertGroup API endpoint (blocking)

In app/static/js/pages/dashboard.js, the new implementation uses:

apiGet("/api/alerts?" + params.join("&"), ...);

However, since IncidentRelay 2.3, the correct endpoint is:

/api/alert-groups

The old /api/alerts endpoint was removed as part of the breaking AlertGroup/Incident API separation.

Please update:

• The Dashboard API requests.
• The new API and OpenAPI tests that reference /api/alerts.
• Any other references to the removed endpoint introduced by this PR.

The existing /api/alert-groups contract must remain backwards-compatible.

3. Verify the updated behavior

Please add or update tests to cover:

• Filtering Active Alerts without affecting global Dashboard metrics.
• Correct behavior with the global Team selector.
• Preserving filters when navigating to the Alerts page.
• Empty results and mobile-friendly filter behavior.
• API requests using /api/alert-groups.

Overall, I support the feature and the backend filtering approach. I would just prefer a more compact, context-specific UX that follows IncidentRelay's existing interface patterns.

Please address the UX changes and the API endpoint issue before merging.

Thanks again for your work on this!