WorkManager retries re-run doWork(): who owns deduplication for write jobs?

WorkManager's documented retry path re-invokes a Worker's doWork() on every attempt, with exponential backoff between runs. Unique work names and ExistingWorkPolicy stop a duplicate work item from being enqueued, but as of the 2.8.x line (worth re-checking against the current release) nothing in the documented API collapses the effects of a retried execution that already performed a write.

That leaves a gap for jobs that mutate persistent state. A Room @Transaction makes a single execution atomic, yet a retry after process death or a network flap can apply the same write twice. The usual mitigation — a persistent flag or idempotency key checked before writing — is entirely developer-supplied, and its behavior across process death and device restarts is not spelled out in the WorkManager documentation.

The unresolved decision is whether deduplication of retried writes should be a framework concern or an application concern:

• Does any documented WorkManager mechanism, in any 2.x release, detect and collapse retried executions of the same logical write?
• If not, is a pre-write idempotency check the intended pattern, and does it hold across process death and reboots?
• Should unique-name semantics be extended to cover a retried run's effects, or is that out of scope by design?