fix: page past the 100-row cap in application pickers

get_pagination_params clamps perpage to MAX_PAGE_SIZE (100) and reports
nothing about having done so, so a caller asking for perpage: 1000 gets the
first 100 rows and a success response. Every picker built that way looked
complete and was not.

Found on a live site with 126 active applications: the 26 sorting last were
absent from the knowledge-base topic dropdown, so an article could not be
filed against them. Nothing was wrong with those application records, and
editing them could never have helped.

Adds fetchAllPages() to the api module, generalizing the one call site that
already handled this correctly (modelsApi.listAll), and points the four
application pickers at a new applicationsApi.listAll(): the KB article form,
the KB list's topic filter, the notification form, and the report filter
builder.

Lists that render a page at a time are untouched - they page for a reason.
Other callers still asking for more than 100 rows of vendors, locations,
models, subnets and the rest are latent: correct only while those tables stay
under 100, and silent on the day they do not.

plugins/knowledgebase/frontend/views/KnowledgeBaseForm.vue

@@ -106,10 +106,13 @@ const applications = ref([])
 onMounted(async () => {
   try {
     // Load applications for topic dropdown
-    const appsRes = await applicationsApi.list({ perpage: 1000, showhidden: true })  // isactive is the only filter that applies to a topic:
-    // ishidden governs whether an application shows on the tiles page, which
-    // says nothing about whether it can be the subject of an article.
-    applications.value = appsRes.data.data || []
+    // listAll, not list: the backend clamps perpage to 100 without saying so,
+    // and the catalogue is past that, so a topic sorting late in the alphabet
+    // was silently missing from this dropdown.
+    // isactive is the only filter that applies to a topic: ishidden governs
+    // whether an application shows on the tiles page, which says nothing about
+    // whether it can be the subject of an article.
+    applications.value = await applicationsApi.listAll({ showhidden: true })
 
     // Load article if editing
     if (isEdit.value) {

plugins/knowledgebase/frontend/views/KnowledgeBaseList.vue

@@ -171,10 +171,13 @@ async function loadArticles() {
 
 async function loadTopics() {
   try {
-    const response = await applicationsApi.list({ perpage: 1000, showhidden: true })  // isactive is the only filter that applies to a topic:
-    // ishidden governs whether an application shows on the tiles page, which
-    // says nothing about whether it can be the subject of an article.
-    topics.value = response.data.data || []
+    // listAll, not list: the backend clamps perpage to 100 without saying so,
+    // and the catalogue is past that, so topics sorting late in the alphabet
+    // were silently missing from this filter.
+    // isactive is the only filter that applies to a topic: ishidden governs
+    // whether an application shows on the tiles page, which says nothing about
+    // whether it can be the subject of an article.
+    topics.value = await applicationsApi.listAll({ showhidden: true })
   } catch (error) {
     console.error('Error loading topics:', error)
   }

plugins/notifications/frontend/views/NotificationForm.vue

@@ -318,7 +318,10 @@ onMounted(async () => {
     const [typesRes, buRes, appsRes, tzRes] = await Promise.all([
       notificationsApi.types.list(),
       businessUnitsApi.list().catch(() => ({ data: { data: [] } })),
-      applicationsApi.list({ perpage: 500 }).catch(() => ({ data: { data: [] } })),
+      // listAll: perpage is clamped to 100 server-side, and the catalogue is
+      // already past that, so this dropdown was missing its tail.
+      applicationsApi.listAll().then(items => ({ data: { data: items } }))
+        .catch(() => ({ data: { data: [] } })),
       settingsApi.get('site_timezone').catch(() => null)
     ])