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/PeerMessage.kt

@@ -31,13 +31,12 @@ import androidx.compose.ui.unit.dp
  *
  * Drawn as its own kind rather than as the reader's own bubble. They did not say this, and a
  * transcript that puts it in their voice is making a claim about who asked for the work that
- * follows -- which is exactly the question a peer message is usually the answer to.
+ * follows.
  *
  * Opened, the card is drawn in *pieces* -- this heading and one [PeerBlockRow] per markdown block,
- * each its own item of the transcript list. See [TranscriptUnit.PeerHead] for the measurements that
- * bought; what matters here is that the pieces have to add up to the card that was there before, so
- * the fill, the corner radius and the padding all live in [peerSurface] rather than being written
- * out at each piece.
+ * each its own item of the transcript list. See [TranscriptUnit.PeerHead] for what that bought;
+ * what matters here is that the pieces have to add up to the card that was there before, so the
+ * fill, the corner radius and the padding all live in [peerSurface].
  */
 @Composable
 fun PeerHeadRow(
@@ -91,9 +90,9 @@ fun PeerBlockRow(unit: TranscriptUnit.PeerBlock, replies: ParsedReplies, onToggl
         // The words shut the card too, and have to do it themselves -- see [LocalMarkdownTap].
         // Without this the card closes everywhere except on the text, which is most of it.
         CompositionLocalProvider(LocalMarkdownTap provides rememberMarkdownTap(onToggle)) {
-            // The gap the card's own column used to provide between its heading and its prose,
-            // and between one block and the next -- inside the piece, so the card's fill runs
-            // through it.
+            // The gap the card's own column used to provide between its heading and its prose, and
+            // between one block and the next -- inside the piece, so the card's fill runs through
+            // it.
             MarkdownPiece(unit.text, unit.piece, replies, Modifier.padding(top = unit.spacing))
         }
     }
@@ -102,16 +101,14 @@ fun PeerBlockRow(unit: TranscriptUnit.PeerBlock, replies: ParsedReplies, onToggl
 /**
  * One piece of a card drawn in slices: the fill, the corners it owns, and the room inside it.
  *
- * A filled Material card is elevation zero ([CardDefaults] takes it from `FilledCardTokens`, which
- * is `Level0`), so there is no shadow that a seam would show through -- which is the whole reason a
- * card can be cut up at all. Each piece paints the caller's container colour the way a
- * [androidx.compose .material3.Card] would and rounds only the corners at the ends of the message,
- * so the pieces abut into one continuous card. Shared by the two rows that are cut this way -- an
- * opened peer message and a long user message -- because two copies of the corner logic is how one
- * of them grows a seam.
+ * A filled Material card is elevation zero, so there is no shadow that a seam would show through --
+ * which is the whole reason a card can be cut up at all. Each piece paints the caller's container
+ * colour and rounds only the corners at the ends of the message, so the pieces abut into one
+ * continuous card. Shared by the two rows cut this way -- an opened peer message and a long user
+ * message -- because two copies of the corner logic is how one of them grows a seam.
  *
- * The padding is the other half of it: 12dp all round was the card's own, so the top piece keeps
- * the top of it, the bottom piece the bottom, and the middle pieces neither.
+ * The padding is the other half: 12dp all round was the card's own, so the top piece keeps the top
+ * of it, the bottom piece the bottom, and the middle pieces neither.
  */
 @Composable
 fun Modifier.cardPiece(