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/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)
     ])