Record reference provenance in manifests

docs/internal/diagnostics.md

@@ -33,6 +33,7 @@ Implemented artifact names:
 - `invocation.json`
 - `effective-config.json`
 - `resolved-pipeline.json`
+- `resolved-references.json`
 - `source-document.json`
 - `run-manifest.json`
 - `run-report.json`

docs/internal/pipeline.md

@@ -42,7 +42,9 @@ During run preparation, resolved file references are materialized before any
 LLM-backed pipeline work. Config bindings resolve relative to the config file,
 CLI bindings resolve relative to the current working directory, and materialized
 reference content is passed to extractors through `ExtractionRequest`.
-Reference content is omitted from diagnostics and manifests.
+Reference content is omitted from diagnostics and manifests. The CLI writes
+provenance-only resolved reference diagnostics, and the run manifest records
+lane-scoped reference provenance separately from source digests.
 
 Prompt bundles can declare reference slots and use `reference` and
 `hasreference` template functions. Bundle loading validates string-literal slot
@@ -176,7 +178,7 @@ On successful execution, the manifest validation status is:
 
 The manifest records run ID, pipeline ID, pipeline digest, module keys, top-level
 module metadata, artifact lanes, LLM profile metadata, source digest,
-validation status, and timing.
+reference provenance, validation status, and timing.
 
 Singleton pipeline modules may add non-secret metadata by implementing
 `contracts.ManifestMetadataProvider`. The runner records that metadata under