docs(reporting): distinguish ledger retention from source recovery

Author: bokelley

docs/reliable-reporting-service.md

@@ -132,8 +132,9 @@ reporting = ReliableReportingService.postgres(
 The PostgreSQL factory makes the ledger durable; it does not make the default
 adapter staging or replay-seal stores durable. Production adapters should pass
 durable `staging=` and `seals=` implementations to `sources.register`, or use
-`sources.register_executor` for a custom executor and object reader. A retained
-revision whose staged rows disappear cannot satisfy an exact read.
+`sources.register_executor` for a custom executor and object reader. Committed revision rows are retained in the ledger for exact reads. Durable
+staging and seals are needed to recover interrupted acquisitions and replay
+previously sealed source results across a restart.
 
 Managed delivery, notification, and receipt components are replaceable
 extensions. Startup rejects combinations that cannot be advertised honestly,

docs/reporting-release-notes.md

@@ -84,8 +84,8 @@ durable wiring and activation. The [service guide](reliable-reporting-service.md
 and [source adapter contract](reporting-source-adapters.md) describe adapter
 registration and lifecycle. The service's PostgreSQL factory makes the ledger
 durable; default adapter staging and replay seals remain in memory. Supply
-durable implementations if retained revisions must remain readable after a
-restart. Multiple service schedulers still need a single account/configuration
+durable implementations for acquisition and sealed-replay recovery across a
+restart. Committed revision rows remain in the durable ledger. Multiple service schedulers still need a single account/configuration
 lease owner until that integration is enabled.
 
 ## Migration and activation