Correct the record: the sort was never the stall

The last commit said the sort explained the 598-frame outlier at 20000 files. A measurement says otherwise: sorting 20000 entries on the JVM takes 3-23 ms, three orders of magnitude short of a ten second iteration. The sort was moved off the main thread on a story that fitted the code instead of the data, and PERFORMANCE.md now says so in those words rather than quietly keeping the claim.

Where the cost actually is, from the ladder itself: 1000 to 5000 files added 27 frames (about 0.45 s) and 5000 to 20000 added 143 (about 2.4 s), which is ~0.1 ms per file with nothing superlinear - readdir plus a stat per entry, on the IO thread but on the critical path to the first row. The outlier is therefore most likely GC or scheduling on top of that, and the honest next step is a perfetto trace of one of those iterations, not another theory.

The off-main sort stays, described as a precaution: 3-23 ms is cheap, but it is work the frame has no reason to wait for.

app/src/main/java/de/softwareapp_hb/filemanager/ui/browser/BrowserViewModel.kt

@@ -329,12 +329,12 @@ class BrowserViewModel(
      * Derives what is shown from [listing]: hidden files filtered out, then sorted.
      *
      * A big folder is sorted on [io] instead of on the caller's thread. `File.listFiles` and the entry
-     * data are already read off the main thread, but the *sort* was not: the default order is natural
-     * order, which parses the digits in every name on every comparison, so twenty thousand rows means
-     * a few hundred thousand string comparisons in the middle of a tap. Measured on the phone at that
-     * size, one iteration out of five took 598 frames against a median of 184 — the kind of hitch this
-     * moves off the frame. Small folders stay on the caller's thread, which keeps the code (and the
-     * tests) honest for the case that happens all the time.
+     * data are already read off the main thread, but the *sort* was not, and with natural order the digits
+     * in every name are parsed on every comparison. Measured on the JVM, twenty thousand entries sort in
+     * **3–23 ms** — cheap enough that this is not the reason the 20 000-file benchmark had one iteration at
+     * 598 frames against a median of 184 (that outlier is still unexplained; see docs/PERFORMANCE.md). It
+     * is moved anyway: work the frame has no reason to wait for belongs off the frame, and the threshold
+     * leaves the common, small folder on the simple synchronous path.
      */
     private fun recompute() {
         val current = _state.value