Stop sending the redundant per_page parameter on every list request

get_pagination_params reads 'perpage' and only falls back to 'per_page', and
this client has always sent 'perpage', so the interceptor's duplicate never did
anything except make every list URL carry a parameter twice.

Removing it also clears a live production problem. The endpoints list route used
to answer a 308, which is a PERMANENT redirect: the browser caches it against
the exact URL including its query string. Clients that hit the old route keep
that rewrite after the server is fixed, because the request no longer leaves the
machine - nothing deployed can reach it, and it fails as mixed content when the
cached target is http. Confirmed in the field: the page failed on load with the
default query string while a search, whose query string differs, worked in the
same session.

Changing the query string changes the cache key, so an affected client misses
the poisoned entry and reaches the corrected route without the user having to
clear site data.

Plugin views that pass per_page explicitly still work - the backend fallback is
untouched. vitest 260 passed.

frontend/src/api/index.js

@@ -16,10 +16,18 @@ api.interceptors.request.use(config => {
   if (token) {
     config.headers.Authorization = `Bearer ${token}`
   }
-  // Send both perpage and per_page for backend compatibility
+  // `per_page` used to be sent alongside `perpage` for backend compatibility.
-  if (config.params?.perpage) {
+  // get_pagination_params reads `perpage` and only falls back to `per_page`, and
-    config.params.per_page = config.params.perpage
+  // this client always sends `perpage`, so the duplicate never did anything -
-  }
+  // it just made every list URL carry a redundant parameter.
+  //
+  // Dropping it also has a one-off benefit worth recording. The endpoints list
+  // route used to redirect (308, PERMANENT and therefore cached by the browser
+  // against the exact URL including its query string). Clients that hit the old
+  // route hold that rewrite even after the server is fixed: the request never
+  // leaves the machine, so nothing deployed can clear it. Changing the query
+  // string changes the cache key, so those clients miss the poisoned entry and
+  // reach the corrected route.
   return config
 })