Persistent queue recovery verification limits in OpenTelemetry Collector

The OpenTelemetry Collector can buffer spans, metrics, and logs to disk using the file_storage extension and a persistent queue so that telemetry survives a backend outage and drains after restart. The queue provides at-least-once delivery, which means an unclean shutdown may cause the Collector to resend events already accepted by the backend.

The Collector does not expose a built-in checksum, manifest, or reconciliation report comparing recovered data against data originally received. Operators must infer completeness from backend-side counts or exporter telemetry, and it is unclear whether that inference is sufficient for environments requiring strict recovery verification.

Can recovered queue data be verified for completeness without external tooling? What Collector metrics or log fields best indicate that a persistent queue has fully drained after restart? Are there documented limits on reconciling duplicates or gaps after an unclean shutdown?