Refactor API routes to separate concerns between HTTP handlers and business logic

[Abh1noob]

📌 Purpose

Refactor API routes by extracting business logic into organized utility functions in the /lib directory.
This improves code maintainability, eliminates duplication, and enhances testability by separating concerns between HTTP handling and business logic.

---

Closes #359

---

🖼️ Showcase

---

🔧 Changes

• Reorganized /lib directory structure for better organization and consistency
• Extracted duplicate escapeRegExp function to src/lib/regex.ts
• Created paper aggregation utilities in src/lib/paper-aggregation.ts for extracting unique values
• Moved Google Sheets operations to src/lib/services/google-sheets.ts
• Added slot calculation logic to src/lib/slot-calculation.ts
• Created paper transformation service in src/lib/services/paper-transform.ts
• Reorganized existing lib files into logical directories:
  • mongoose.ts → lib/database/mongoose.ts
  • pdf.ts → lib/storage/pdf.ts
  • storage.ts → lib/storage/gcp.ts
  • utils.ts → functions split across specialized files in /lib
• Refactored 5 API routes to use new utility functions:
  • /api/papers/route.ts
  • /api/related-subject/route.ts
  • /api/subscribe/route.ts
  • /api/upcoming-papers/route.ts
  • /api/user-papers/route.ts
• Removed utils folder — functions now live directly in the lib folder, grouped by domain
• UI-based component Capsule moved from utils to /components folder

---

🆕 Additional Notes

• We need to cleanup public folder with the same purpose of logical grouping of entities
• Component names needs to be consistent

---

✅ Benefits

• No breaking changes — all existing functionality is preserved
• Better separation of concerns — API routes now focus purely on HTTP handling
• Eliminated code duplication — shared utilities are now centralized
• Consistent file organization in lib — clear directory structure makes the codebase more maintainable