feat(management): add dashboard.applicationsOverview for dashboard apps enumeration

[scthornton]

Summary

Adds mgmt.dashboard.applicationsOverview() to enumerate the dashboard's apps view. This is the canonical apps-list source for the SCM "AI Security > Runtime > API Applications" panel, and is needed because the existing customerApps.list() enumeration is at the wrong granularity for per-bucket reporting.

This is the SDK half of cdot65/prisma-airs-cli#240. The CLI-side change to use this new endpoint will follow in a separate PR.

Why this is needed

The dashboard buckets traffic by the literal metadata.app_name value scan payloads sent. A single registered customer-app (customer_apps.customer_appId) can therefore appear in the dashboard as multiple buckets, one per distinct scan-payload name, when an integration overrides app_name in scan metadata. LiteLLM's panw_prisma_airs guardrail does this by default; Portkey and Kong wrappers commonly do too.

Concrete example from a live tenant on 2026-05-29: 5 customer_apps entries but 20 dashboard buckets returned by applicationsoverview. CustomerApp 5e16929a-... alone had 8 distinct buckets (chatbot, Claude Code, LiteLLM, Portkey, kong-airs-demo, ...) each with its own real token_stats. The current CLI that enumerates from customerApps.list() was emitting one row per customer_app and silently dropping every other bucket.

API behavior (verified live 2026-05-29)

GET /v1/mgmt/dashboard/v2/apps/applicationsoverview

Query param	Accepts
time_interval	1, 7, 30, 60. Others return HTTP 400.
time_unit	'days', 'day', 'hour'. Note this endpoint accepts the singular forms (unlike application which is 'days'-only).
limit	Any positive int. SCM UI uses 25.
offset	0-based pagination offset.

Valid live-tested combinations: (7, days), (30, days), (60, days), (1, day), (1, hour). All others return 400. The SDK defaults to (30, days) to match the existing dashboard methods, but the wider enum is reflected in the type signature so callers can use the shorter windows.

Response:

{
  items: [{
    id: string,                  // registered customer_appId UUID
    name: string,                // scan-payload metadata.app_name literal
    cloud: string,
    source: string,              // 'api', etc.
    created_at: string,
    sessions: [{ bucket_number, date, total, violated }],
    sessions_total: number,
    sessions_violated: number,
  }],
  pagination: { limit, skip, total_items },
}

The id field matches customer_apps.customer_appId. The name field is the literal scan-payload value. Together they form the lookup key the existing dashboard.application(query) and dashboard.applicationViolationBreakdown(query) methods expect.

What this PR adds

• MGMT_DASHBOARD_APPLICATIONS_OVERVIEW_PATH constant
• DashboardApplicationsOverviewSchema + DashboardApplicationsOverview type (plus the per-item, sessions-bucket, and pagination schemas)
• DashboardClient.applicationsOverview(query?) method
• DashboardApplicationsOverviewQuery input type with narrowed enums
• 5 new unit tests:
  • GET with defaults (verifies path + default params)
  • Same item ids with distinct names produce distinct buckets (the data-model assertion)
  • Caller-supplied timeInterval / timeUnit / limit / offset
  • Singular (1, hour) time window
  • Empty items array tolerance
• Changeset (minor)
• JSDoc cross-references between DashboardAppQuery.appName and applicationsOverview so callers can navigate the relationship

Existing application and applicationViolationBreakdown methods are unchanged.

Verification

• Build clean (npm run build)
• Lint clean (npm run lint)
• Typecheck clean (npm run typecheck)
• Preflight: 0 unacknowledged drift (npm run preflight)
• All 1279 tests pass (npm test), including 10 dashboard tests (5 existing + 5 new)
• Live-tested against my own tenant (api.sase.paloaltonetworks.com) on 2026-05-29

Follow-ups (not in this PR)

Two adjacent endpoints the SCM UI uses on the same page, wrapped here for future SDK work if useful:

• dashboard/v2/apps/topapplicationsviolations - top-N apps by violation count, per-detector totals
• dashboard/v2/apps/applicationsviolationstrend - violation time-series

Neither is needed for the cdot65/prisma-airs-cli#240 fix.