feat(saas-admin): add platform-operator dashboard and tenant commercial self-service views #878

Parent epic: #868
Depends on: #870, #871, #872, #873, #875, #876, #877

Context

The control-plane modules need one coherent management surface. Separate low-level pages without a unified information architecture would make provisioning failures, entitlement sources, usage freshness, invoices, payments, and lifecycle restrictions difficult to understand and unsafe to operate.

Objective

Add accessible, permission-gated platform-operator administration and bounded tenant self-service views that reuse each module's application services and authorization rules.

Scope

Platform-operator surfaces

• Control-plane overview with health, backlog, stale projections, failed provisioning, overdue invoices, payment mismatch, and suspended tenants.
• Tenant directory and detail timeline.
• Service catalog/plan/version management.
• Effective entitlement explanation and controlled override/revoke.
• Provisioning request/status/resume/reconcile/manual-intervention actions.
• Tenant lifecycle transition/schedule/restore views.
• Usage meter/aggregate/freshness/correction/reconciliation views.
• Subscription/invoice/credit/dunning management.
• Payment intent/webhook/retry/DLQ/refund/reconciliation/provider-health views.

Tenant-facing surfaces

• Current plan/version and effective features/quotas.
• Usage and quota status with freshness information.
• Subscription status, invoices, credits, payment status, and hosted checkout initiation when enabled.
• Upgrade/downgrade/cancel request workflow where policy allows.
• Read-only lifecycle status and support/recovery guidance.

Cross-cutting

• Search/filter/pagination/export only where authorized and bounded.
• Loading, empty, error, stale, partial, blocked, and success states.
• Indonesian/English i18n parity.
• WCAG-aware forms, tables, focus, keyboard navigation, validation, and status announcements.
• CSP-safe external scripts and no inline unsafe behavior.
• Route/module/permission navigation derived from existing registries.

Out of scope

• Public marketing/pricing website.
• Vertical-application onboarding UI.
• Provider-specific dashboards replacing provider portals.
• Authorization enforcement only in the UI; server-side services remain authoritative.

Security and privacy requirements

• Platform and tenant navigation/actions are separated by explicit permissions and scope.
• Sensitive provider references, contact data, invoice details, and webhook evidence are masked by default.
• High-risk actions require reason, confirmation, audit, idempotency, and step-up/SoD integration where defined by security(saas-control-plane): enforce platform/tenant separation, SoD, step-up, privacy, and support-access controls #879.
• Tenant users never see another tenant through search, count, autocomplete, export, or error messages.
• Bulk actions are bounded, dry-run where appropriate, and cannot silently cross tenants.
• UI never displays secret values or raw webhook tokens/payloads.

Acceptance criteria

• Platform operator can complete the primary control-plane workflows without direct database/API tooling.
• Tenant user can understand plan, entitlement source, quota/usage freshness, subscription, invoice, and payment status.
• Every action is permission-gated in UI and re-authorized server-side.
• Cross-tenant negative E2E tests cover list, detail, search, export, and mutation paths.
• All screens have responsive and accessible states and i18n parity.
• Sensitive identifiers and provider evidence are masked/redacted.
• Direct URL access to disabled/unentitled modules is denied consistently with API behavior.
• Navigation and API documentation remain generated/checked where applicable.

Testing

• Unit/component tests for formatting, masking, states, and permission visibility.
• Browser E2E for platform operator and tenant self-service critical journeys.
• axe-core accessibility and keyboard tests.
• Cross-tenant/role-negative E2E.
• CSP regression test ensuring no unsafe inline script/style behavior.
• Large-list pagination/filter performance smoke.

Documentation

• Information architecture, role/permission matrix, platform operator guide, tenant billing guide, accessibility checklist, screenshots/wireframes if maintained, module navigation docs, and changeset.

Dependencies

Security-sensitive actions must adopt #879 controls; operational indicators are finalized by #880.