feat: add date range filter to PR analytics widget

[Srishti-Gupta74]

Summary

Adds a date range filter (7d / 30d / 90d) to the PR Analytics widget and connects it to the backend metrics API. PR analytics data now updates dynamically based on the selected time range, providing a more consistent analytics experience across the dashboard.

Closes #2453

---

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 💥 Breaking change (fix or feature that changes existing behavior)
• 📝 Documentation update
• ♻️ Refactor / code cleanup (no functional change)
• ⚡ Performance improvement
• 🔒 Security fix
• 🧪 Tests only

---

What Changed

• Added a 7d / 30d / 90d range selector to the PR Analytics widget (src/components/PRMetrics.tsx)
• Passed the selected range as a query parameter to the PR metrics API
• Triggered analytics refetching whenever the selected range changes
• Updated PR metrics backend logic (src/app/api/metrics/prs/route.ts) to filter metrics based on the selected date range
• Updated metrics cache keys to include the selected range and prevent cache collisions
• Replaced the previously hardcoded 90-day filtering logic with the user-selected range
• Applied minor code formatting improvements within the modified files

---

How to Test

1. Run the application locally using npm run dev
2. Navigate to the dashboard and open the PR Analytics widget
3. Verify that the new range selector displays 7d, 30d, and 90d options
4. Switch between the available ranges
5. Confirm that analytics data refreshes when the selected range changes

Expected result:

• The range selector is visible in the PR Analytics widget
• API requests include the selected range query parameter
• PR analytics metrics update based on the selected time range
• Build and lint checks pass successfully

---

Screenshots / Recordings

Before	After
PR Analytics displayed all-time data without a range selector	Added a 7d / 30d / 90d range selector with range-aware analytics updates

---

Checklist

• Linked the related issue above
• Self-reviewed my own diff
• No unnecessary console.log, debug code, or commented-out blocks
• npm run lint passes locally
• No TypeScript errors (npm run type-check)
• Added or updated tests where applicable
• Updated documentation / comments if behavior changed

---

Accessibility (UI changes only)

• Keyboard navigation works correctly
• Color contrast meets WCAG AA standard
• ARIA labels / roles added where needed
• Tested on mobile / responsive layout

---

Additional Context

This implementation reuses the existing date-range filtering pattern already used elsewhere in the dashboard. The selected range is propagated through the frontend, API layer, caching logic, and analytics calculations to ensure all PR metrics remain consistent with the chosen time window.

[github-actions]

GSSoC Label Checklist 🏷️

@Umbrella-io — please apply the appropriate labels before merging:

Difficulty (pick one):

• level:beginner — 20 pts
• level:intermediate — 35 pts
• level:advanced — 55 pts
• level:critical — 80 pts

Quality (optional):

• quality:clean — ×1.2 multiplier
• quality:exceptional — ×1.5 multiplier

Validation (required to score):

• gssoc:approved — counts for points
• gssoc:invalid / gssoc:spam / gssoc:ai-slop — does not score

Type labels (type:*) are auto-detected from files and title. Review and adjust if needed.
Points formula: (difficulty × quality_multiplier) + type_bonus

[Srishti-Gupta74]

Hi @Priyanshu-byte-coder! I took a look at the failing checks and they seem to be coming from existing Playwright tests rather than the changes in this PR.

The failures are currently in:

• e2e/streak.spec.ts
• tests/visual/visual-regression.spec.js

I also verified locally that the project builds successfully and passes:

• npm run lint
• npm run type-check
• npm run build

Happy to investigate the Playwright failures as well if needed.