Pub/Sub subscription retry policy and duplicate write prevention

Pub/Sub subscription retry policy controls minimum and maximum backoff for redelivery after nack or ack deadline expiry. The configuration affects delivery timing, not delivery semantics.

The documented delivery guarantee is at-least-once. The API surfaces messageId per delivery, but there is no built-in deduplication window or correlation identifier provided by the service for retries. Applications are expected to implement idempotency for writes.

Behavior may differ across tiers and regions, and ack deadline settings interact with retry timing. The unresolved design point is whether deduplication on retry will remain entirely subscriber-side or become a configurable service behavior.

Does the current retry policy configuration expose any deduplication-related constraint or window? Is the responsibility for deduplication documented as a permanent subscriber-side requirement? Is a service-managed deduplicate-on-retry option under consideration?