fix(analytics): validate range parameter and return 400 for unsupport…

[jikrana1]

Closes #858

Problem description

The getTrends endpoint currently falls back to the default daily range whenever an unsupported range value is provided (e.g., ?range=yearly). This silent fallback hides client-side mistakes and makes debugging more difficult because invalid requests still return successful responses.

Proposed solution

Added explicit validation for the range query parameter.

Implementation details:

• Check if range is present and not in ANALYTICS_RANGES (daily, weekly, monthly).
• If invalid, return a 400 Bad Request with a clear error message listing the supported values.
• If range is not provided, keep the existing default behavior (daily).
• Preserves all existing functionality for valid requests.

Benefits

• ✅ Improves API validation.
• ✅ Makes debugging easier for client developers.
• ✅ Prevents unintended analytics results due to typos.

Testing instructions

1. Call /analytics/trends?range=yearly. Should return a 400 Bad Request error.
2. Call /analytics/trends?range=daily. Should return the daily trends normally.
3. Call /analytics/trends without any range. Should still default to daily and return data.

[vercel]

Someone is attempting to deploy a commit to the Aditya Sharma's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Userunknown84]

Merge Conflict shown.

[Userunknown84]

Merge conflict