The four non-blocking notes from the #7 review. No behaviour change: one
test and four corrected sentences.

The fill-refused branch — the strike, the release, the exhaustion backstop
and the cause riding along — was added in answer to the first review round
and is the one part of claimFinalName nothing pinned. On Linux a fill is
never refused (unlink of an open file just works), so 3000 rounds of the
concurrency test walk past it; it was exercised only incidentally, on the
Windows desk, by a scanner holding the fresh placeholder. A temp that does
not exist refuses every fill deterministically, on either host, and one
test then covers all four properties. Verified by mutation: dropping
target.delete() fails it, and so does dropping `refused` from the throw.

The KDoc claimed the stranded zero-byte placeholder needs a process death.
It does not — target.delete()'s result is ignored, and the scanner that
refuses the fill can refuse the release too, stranding the same corpse with
no crash involved. The loss is a claim this transfer could not release,
whatever stopped it; that the result is not worth branching on is now said
rather than implied.

It also argued the race from "two pages on the back stack" without saying
where: claimFinalName is the else of SDK_INT >= Q, so it only ships to
API 26-28. Android 10 and up settle the name in MediaStore's insert, which
dedupes atomically and hands the landed name back — no check-then-claim
there to race. Worth having next to the reasoning rather than found again
by whoever touches the Q+ path.

And "on the desk, where these tests run" put them in one place; they run on
the Windows desk and on cth-ubuntu-latest, twice per push to main. The
reason for ATOMIC_MOVE over renameTo is exactly that, so the clause was
undercutting its own argument.

spotlessCheck, lintDebug and testReleaseUnitTest green locally (13/13 in
DownloadNamingTest). No versionName bump: nothing here reaches a device.

Refs #10.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

@@ -337,1 +334,3 @@
- * past it. The racers above are two ViewModels in one process — an
+ * Only on API 26-28: this is [downloadToAppDownloads], the `else` of
+ * `SDK_INT >= Q`. From Android 10 a download goes through MediaStore, whose
+ * insert dedupes the display name atomically and hands the landed name back —

@@ -361,3 +369,3 @@
  *
- * One loss is accepted: a process death between the claim and the rename
+ * One loss is accepted: a claim this transfer never manages to release
  * strands the placeholder as a zero-byte file under the final name, and the

@@ -367,0 +374,4 @@
+ * the other, and it needs no crash — the scanner that refuses the fill can
+ * refuse the release too, which is why that result is not worth branching
+ * on. (Not a shipping concern: Android unlinks an open file, as does Linux,
+ * so the release only fails on Windows.) No sweep can take the corpse back

@@ -186,0 +187,4 @@
+                // can also flake honestly: a scanner that refuses the fill
+                // can refuse the release, and the corpse is then a real
+                // extra name. Left strict rather than loosened, because on
+                // both hosts CI runs it is the assertion that would catch a

@@ -193,0 +200,4 @@
+    fun `a fill the filesystem refuses leaves no placeholder behind`() {
+        val downloads = Files.createTempDirectory("downloads").toFile()
+        try {
+            // the branch the concurrency test cannot reach: on Linux a fill

@@ -193,0 +213,4 @@
+            } catch (e: IllegalStateException) {
+                e
+            }
+            assertTrue(

@@ -193,0 +218,4 @@
+            )
+            // the refusal itself rides along, or the log says only that
+            // 1000 candidates were tried and not one word about why.
+            // java.nio.file's, imported over kotlin.io's same-named one,