Thin the app's comments

The same pass the server had, on the Kotlin side: comments restating what
the code says are gone, and the ones recording a measurement, a constraint
or an incident are kept but cut to a few lines each. 6540 comment lines to
5674, and 920 lines off the app.

Two doc comments had drifted onto the item above the one they describe --
`contextAfter`'s onto `sessionWorking` in Events.kt, and `UsageMonitor`'s
equivalent on the server was fixed in the previous commit. Each is back on
its own item, which is the only non-comment line this diff moves.

The comments are reflowed to the column limit at their own indentation:
several were written wide, and ktfmt re-wrapped them into lines holding a
single orphan word. `/tmp` script, not kept -- ktfmt is idempotent over the
result, which is the check.

Left alone deliberately: this codebase's remaining comment density is high
because the comments carry things the code cannot say -- what a null means,
what a number was measured against, which bug a guard exists for. Of the
238 one-line doc comments in the app, five were pure restatement of the
name and were removed; the rest each say something the signature does not.

ktfmtFormat, compileDebugKotlin, lintDebug and testDebugUnitTest pass;
cargo test (127), clippy --all-targets and fmt still clean.

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

app/androidApp/src/main/kotlin/com/example/aiapp/TranscriptSource.kt

@@ -9,14 +9,12 @@ import java.util.concurrent.atomic.AtomicReference
  * rest.
  *
  * One seam rather than a cache the screen has to remember to consult. Everything it fetched before
- * -- the opening window, the pages it scrolls back through, the span an anchor restore reaches for
- * -- is asked of this, and everything the server sends is written into the cache on the way past,
- * so the screen never learns which side answered. What it does learn, through [DebugStats], is how
- * often each one did, which is how the saving is measured.
+ * is asked of this, and everything the server sends is written into the cache on the way past, so
+ * the screen never learns which side answered. What it does learn, through [DebugStats], is how
+ * often each one did.
  *
- * See TRANSCRIPT_CACHE.md. The one rule worth keeping in mind here: the cache is never
- * load-bearing. Every read has a network path beside it producing the same result, so a missing,
- * evicted or damaged cache degrades to exactly what this screen did before it existed.
+ * See TRANSCRIPT_CACHE.md. The one rule worth keeping in mind: the cache is never load-bearing.
+ * Every read has a network path beside it producing the same result.
  */
 class TranscriptSource(
     private val settings: ServerSettings,
@@ -51,18 +49,17 @@ class TranscriptSource(
      *
      * The screen must not resume a stream from a cached seq unless it is the same conversation. A
      * transcript is append-only in ordinary use, but the file can be replaced or truncated -- a
-     * sandbox re-seeded with the same ids, a backup restored, a directory deleted and the session
-     * re-imported -- and the server's catch-up on such a file would hand this phone a continuation
-     * of a *different* conversation, spliced onto the cached one with no seam. That is the worst
-     * thing this feature can do, and it is caught with one request of a few hundred bytes, in the
-     * slot the opening page's request used to be in.
+     * sandbox re-seeded with the same ids, a backup restored, a session re-imported -- and the
+     * server's catch-up on such a file would hand this phone a continuation of a *different*
+     * conversation, spliced onto the cached one with no seam. Caught with one request of a few
+     * hundred bytes, in the slot the opening page's request used to be in.
      *
      * False purges the cache and means "open cold". A throw is the server not being askable, which
-     * is neither: the cached rows stay on screen, the failure goes on the stream banner, and the
-     * caller tries again on the stream's own reconnect schedule.
+     * is neither: the cached rows stay on screen and the caller tries again on the reconnect
+     * schedule.
      *
      * What this cannot see is a line changed in the middle of the file with the tail intact. That
-     * is what the Reload button in session settings is for, and its caption says so.
+     * is what the Reload button in session settings is for.
      */
     suspend fun probe(): Boolean {
         val tail = cache.tail() ?: return false
@@ -100,8 +97,7 @@ class TranscriptSource(
      * row count takes it -- a single reply is hundreds of lines -- so a page fetched after the
      * reader has been away would run straight past the cached run and overlap it, and an
      * overlapping page cannot be stored. Told where this phone's copy starts, the server stops
-     * there instead, the gap is closed with exactly the bytes it was wide, and the history behind
-     * it is served locally from then on.
+     * there instead.
      */
     suspend fun page(before: Long, limit: Int, coalesce: Boolean): List<SeqEvent> {
         cache.page(before, limit, rows = coalesce)?.let { lines ->
@@ -169,10 +165,8 @@ private const val OPENING_WINDOW = 80
  *
  * Under `cacheDir` because that is exactly what it is for: bytes the phone can regenerate from the
  * server, which Android may delete under storage pressure without asking. Keyed by host and port
- * because two servers can hold a session with the same id -- the sandbox and the real server, or a
- * re-enrolment -- and a line from one shown against the other is the whole invariant broken. `v1`
- * is the layout's version: a change to it bumps the segment, and a directory of another version is
- * deleted the first time this is called.
+ * because two servers can hold a session with the same id, and a line from one shown against the
+ * other is the whole invariant broken. `v1` is the layout's version.
  */
 fun cacheRoot(context: Context, settings: ServerSettings): File {
     val transcripts = File(context.cacheDir, "transcripts")