Pagination cap forces every page up to the max instead of capping large requests down

GET /api/forms/<id>/submissions is the endpoint an owner's dashboard calls to show a page of recent responses. A well-behaved dashboard asks for a small page (per_page=10 or per_page=20, say, to keep a widget snappy) and expects to get back roughly that many rows. Right now, any per_page smaller than the server's cap (PAGINATION_MAX_PER_PAGE=100) is silently ignored and the full 100-row cap is used instead. For a form with thousands of submissions, that means every "give me a small page" request actually downloads up to 100 full submission objects (including nested attachment metadata) -- extra database load on every dashboard paint, slower page loads for the owner (especially on mobile, where this kind of dashboard is often checked), and wasted bandwidth for something that was supposed to be a lightweight, paginated call. It also silently breaks any owner-facing "results per page" UI control, since the server ignores whatever smaller value the UI sends.

paginate_query(query, page, per_page, max_per_page) is supposed to cap an oversized per_page down to max_per_page, while leaving a smaller per_page alone. Instead it forces per_page up to max_per_page whenever the caller's value is smaller, and, as a direct consequence of the same bug, also stops capping oversized values down at all.

cd flask/feedback_service export FLASK_ENV=testing FLASK_ENV=testing .venv/bin/python -m pytest ticket_tests/test_ticket_02_pagination_ignores_small_per_page.py -v

Both tests fail: a request for per_page=2 against a form with 5 submissions comes back

with all 5 items instead of 2, and per_page=99999 is honored as-is instead of capped to 100.

min() and max() are easy to swap by accident (they are one character apart in most people's typing rhythm, and both "sound" plausible for "a cap"), and unlike many off-by-ones, swapping them does not produce an obviously-broken result for the common case -- a page of default size (20) is still well under the cap of 100, so this bug is invisible unless someone specifically requests a small per_page. That is exactly the kind of bug that survives casual manual testing and ships to production.

paginate_query takes the caller's requested per_page and the server's configured ceiling, and is supposed to produce "whichever is smaller." Re-derive that logic from the plain-English description above rather than trusting the existing line -- and once fixed, check both directions (a small request, and an oversized request) rather than just the one you originally noticed.