feat(api): Implement Zod runtime validation and strict rate limiting (fixes #52)

[Diwakar-odds]

Closes #52

Summary

The Next.js API routes (like /api/issues/feed/route.ts) parsed
eq.json()\ directly without runtime validation and lacked rate limiting, leaving the GitHub API integration vulnerable to abuse and exhaustion of rate limits. This PR introduces robust Zod runtime validation and an Upstash Redis rate limiting layer to harden backend security.

Motivation

Validating request payloads rigorously and restricting request frequencies via distributed rate limiting satisfies L3 security criteria by eliminating invalid inputs before processing and mitigating abuse and potential DoS vectors on backend wrappers.

Changes

• Integrated \zod\ for request payload validation.
• Integrated @upstash/ratelimit\ and @upstash/redis\ for distributed rate limiting.
• Refactored the /api/issues/feed\ POST route to validate the \languages\ and \page\ parameters via a Zod schema.
• Applied a fixed-window (sliding-window) rate limiter (10 req/min) to reject excessive requests with 429 status codes.

Acceptance Criteria

• Integrate \zod\ for request payload validation.
• Integrate @upstash/ratelimit\ and @upstash/redis\ for distributed rate limiting.
• Refactor the /api/issues/feed\ POST route to validate the \languages\ and \page\ parameters via Zod.
• Apply a fixed-window rate limiter to reject excessive requests with 429 status codes.

Impact & Side Effects

Invalid request payloads will now receive a \400 Bad Request\ response. Requests exceeding 10 per minute per IP will receive a \429 Too Many Requests\ response.

How to Test

1. Make a POST request to /api/issues/feed\ with valid payload parameters to see normal 200 response.
2. Provide invalid data (e.g., non-array languages) and observe a 400 response.
3. Burst requests to trigger the 429 rate limit response.

Quality Checklist

• Code follows project conventions.
• No scratch files or unrelated changes included.

[vercel]

@Diwakar-odds is attempting to deploy a commit to the suyashyadav1709-9626's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Diwakar-odds]

Hi maintainers, could you please review this PR?

Technical Analysis & ECSoC26 Label Request

This PR directly hardens the core API infrastructure by integrating Zod runtime payload validation and Upstash Redis distributed rate limiting on the /api/issues/feed route.

By preemptively validating all incoming schemas via Zod, we mitigate data inconsistencies and injection risks. Furthermore, implementing a sliding window rate limit directly prevents DoS vectors and limits abuse on our proxied GitHub API requests. This addresses fundamental backend security and API resiliency.

Given that this is a direct security hardening enhancement to the core backend infrastructure, it fully aligns with the Level 3 (Core/Arch/Perf) requirements.

Could you please add the following labels?

• \ECSoC26\
• \Level 3\
• \good-backend\
• \good-pr\

Thank you!