Pin reporting datasets to published Dataflow runs

docs/ADMIN_GUIDE.md

@@ -27,6 +27,10 @@ published by a source-owning module. Do not expose another module's ORM or an
 unbounded SQL connection as a report source. Configure an explicit schema,
 freshness policy, source fingerprint expectations, purpose, privacy,
 retention, and a row-policy provider where source access alone is not enough.
+For a Dataflow source, `source_run_ref` optionally pins one successful run that
+published an immutable Datasource materialization. Reporting passes this pin
+through rather than re-executing the pipeline. The current principal must still
+be authorized for the Dataflow definition and the exact Datasource output.
 
 On PostgreSQL installations, Reporting compiles bounded semantic filters,
 grouping, measures, calculated measures, ordering, offsets, and limits into a

docs/USER_GUIDE.md

@@ -28,6 +28,11 @@ the exact definition and output. Warnings explain freshness, inferred schema,
 or provider diagnostics. A failed quality gate records a failed execution and
 does not publish a result.
 
+A report configured against an exact published Dataflow run reads that run's
+immutable Datasource materialization. It does not rerun the flow with current
+inputs. The evidence identifies the Dataflow run and materialization, and access
+to both is checked again when the report runs.
+
 The **Effective access** explanation states when dimensions, measures, source
 rows, or actions were removed by Policy. A result with no hidden elements says
 so explicitly; catalogue visibility never grants access to protected detail.