Unbounded API responses on /rest/v1/root_cres and /rest/v1/all_cres

Issue

What is the issue?

Two REST endpoints can return unbounded result sets, causing high memory usage and potential timeouts in production.

/rest/v1/root_cres has no pagination at all. It calls get_root_cres() which runs a full table scan with no limit and returns every root CRE in a single response. There is no way for clients to page through results.

/rest/v1/all_cres already has pagination but accepts any positive integer for per_page. Passing ?per_page=999999 fetches the entire dataset in one request, defeating pagination entirely. There is no MAX_PER_PAGE cap anywhere in the codebase.

Expected Behaviour

/rest/v1/root_cres should support page and per_page query parameters and return pagination metadata (page, total_pages) alongside data, consistent with how /rest/v1/all_cres already works.

/rest/v1/all_cres should enforce an upper bound on per_page so that a single request cannot retrieve the entire dataset regardless of what value is passed.

Actual Behaviour

/rest/v1/root_cres returns all root CREs in a single unbounded response with no pagination support.

/rest/v1/all_cres accepts ?per_page=999999 and returns the entire dataset in one response.

Steps to reproduce

GET /rest/v1/root_cres
# returns all root CREs, no page/total_pages in response

GET /rest/v1/all_cres?per_page=999999
# returns entire dataset in one response

Start by locating the handlers for /rest/v1/root_cres and /rest/v1/all_cres, then trace get_root_cres() and the existing pagination logic. Confirm how pagination metadata is built for all_cres, identify where per_page is validated, and define done as bounded responses for both endpoints with page and total_pages returned by root_cres.