feat: define governed report provider contract

docs/MODULE_ARCHITECTURE.md

@@ -823,6 +823,10 @@ WebUI modules receive only the core route context:
 - `auth`
 
 A module should call its own API client and module-owned backend routes. Shared API helpers should live in core only when they are truly platform-level concerns.
+For ordinary JSON mutations, use Core's `apiPostJson` and `apiPatchJson`
+helpers. They preserve the shared authentication, CSRF, error, and request
+invalidation behavior while leaving endpoint types and feature semantics in the
+owning module.
 
 Modules can also contribute named UI capabilities for explicit extension
 points. Capability values must be narrow, typed contracts, not imports from a
@@ -1005,6 +1009,16 @@ Decision: templates and reporting are separate modules.
   and export targets
 - report permissions, report execution history, generated report evidence, and
   report-specific retention inputs
+
+Cross-module reports use Core's versioned
+`reporting.report_provider.<provider-id>` contract. Source modules own
+authorization, parameters, source revisions, effective scope, result schema,
+and privacy transforms; Reporting owns discovery, validation, governed
+execution, provenance, export history, and the global `/reports` route. The
+optional `policy.reporting_governance` capability can only tighten execution,
+retention, export, and re-identification-risk handling. Reporting exposes
+`reporting.retention` so the Policy-owned retention run can minimize expired
+provider results without importing Reporting models.
 - downstream export handoff to files, dataflow, connectors, or publication
   surfaces