[bug]: Work items API returns HTTP 500 for per_page=0 or negative values instead of a validation error

Describe the bug

The work items list endpoint validates the per_page query parameter inconsistently. Non numeric and oversized values are rejected with a clear 400 response, but zero and negative values crash with an unhandled 500.

Steps to reproduce

Call the public API work items list endpoint with different per_page values (Plane Cloud, tested 2026-07-16):

GET /api/v1/workspaces/{slug}/projects/{project_id}/issues/?per_page=abc
→ 400 {"detail": "Invalid per_page parameter."}

GET .../issues/?per_page=100000
→ 400 {"detail": "Invalid per_page value. Cannot exceed 1000."}

GET .../issues/?per_page=0
→ 500 {"error": "Something went wrong please try again later"}

GET .../issues/?per_page=-5
→ 500 {"error": "Something went wrong please try again later"}

Expected behavior

per_page=0 and negative values should return a 400 with a message like the other invalid cases, for example "Invalid per_page value. Must be a positive integer."

Why it matters

A 500 tells the API consumer the server failed, so clients typically retry, when the real problem is invalid input that will never succeed. The existing validation already catches non numeric and too large values, so this looks like a small gap in the same check.

Environment

Plane Cloud (app.plane.so), public REST API v1, personal API token auth.

Start at the public API work items list endpoint and trace the existing per_page validation that handles non-numeric and oversized values. Reproduce the zero and negative cases, then add coverage for their expected 400 responses alongside the existing invalid-input cases. Done means both values return a clear validation error instead of HTTP 500.