Backend: Inconsistent request validation and error contracts across API endpoints

Several backend API endpoints currently lack consistent request validation and error handling, leading to undefined behavior, silent failures, and potential server errors when clients send malformed or incomplete requests.

While some question-generation endpoints (e.g. /get_mcq, /get_boolq, /get_shortq) perform basic defensive validation, many other endpoints do not validate inputs at all or return successful responses even when requests are invalid.

This results in:
• 500 errors due to missing or malformed JSON bodies
• Silent success responses for invalid payloads
• Inconsistent HTTP status codes and response schemas
• Unclear API contracts for frontend consumers
Examples of current issues
• request.get_json() is used without guarding against None in multiple endpoints
• Some endpoints return 200 OK with empty outputs on invalid input instead of 400
• No type or range validation for numeric fields (e.g. max_questions)
• Validation logic is duplicated inconsistently instead of being reused
• Error responses are not standardized across endpoints

⸻

Proposed direction
• Introduce consistent defensive validation across all API endpoints
• Ensure invalid requests return appropriate HTTP 400 responses with clear JSON error messages
• Avoid changing successful behavior or generator logic
• Keep scope limited to request validation and error handling

This will improve backend robustness, reduce runtime errors, and provide a clearer contract for frontend integration.

⸻

Notes

This issue intentionally focuses on API correctness and safety, not refactoring model logic or changing response formats.