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

@@ -17,14 +17,13 @@ const val RECONNECT_DELAY_MS = 1500L
  * One server-sent-events connection, framed.
  *
  * The framing is the part worth having once: `data:` and `event:` lines accumulate until a blank
- * line ends the frame, comments (keep-alives) start with `:`, and a frame is either named with no
- * payload or a payload with no name. Two screens follow two different streams — a session's
- * transcript and what a machine's import list is doing — and neither should be re-deriving that.
+ * line ends the frame, comments start with `:`, and a frame is either named with no payload or a
+ * payload with no name. Two screens follow two different streams and neither should re-derive that.
  *
  * Blocking: [run] occupies its thread until the stream ends. [close], from any thread, is the
- * cancellation path — it disconnects the socket, which unblocks the read, and [run] then returns
- * rather than throwing, so a deliberate close is not reported as a connection error. Reconnecting
- * belongs to the caller, which is the only one that knows where to resume from.
+ * cancellation path -- it disconnects the socket, which unblocks the read, and [run] then returns
+ * rather than throwing. Reconnecting belongs to the caller, which is the only one that knows where
+ * to resume from.
  */
 class Sse(private val settings: ServerSettings) {
     @Volatile private var connection: HttpURLConnection? = null
@@ -38,19 +37,16 @@ class Sse(private val settings: ServerSettings) {
     /**
      * Follows the stream at [path], handing each frame to [onFrame] as its name (null for an
      * ordinary data frame) and its payload. The path is given here rather than at construction
-     * because a caller that reconnects usually resumes from somewhere new -- a cursor it has
-     * advanced past -- and that lives in the query string.
+     * because a caller that reconnects usually resumes from somewhere new.
      *
      * [onOpen] fires once the server has accepted the connection. That is the measured moment the
      * stream is live, and the only honest thing to clear a previous failure on: clearing on the
-     * first *event* instead left an idle stream displaying a connection error it had already
-     * recovered from, indefinitely.
+     * first *event* instead left an idle stream displaying an error it had already recovered from.
      */
     fun run(path: String, onOpen: () -> Unit, onFrame: (name: String?, data: String) -> Unit) {
         // Opening is inside the try, not before it. Everything this method can fail at owes the
-        // caller the same kind of failure -- both callers retry an [ApiException] and let anything
-        // else reach the top of the app -- and a connection that could not even be constructed
-        // used to escape as a raw `IOException` from a line no `catch` covered.
+        // caller the same kind of failure, and a connection that could not even be constructed used
+        // to escape as a raw `IOException` from a line no `catch` covered.
         var connection: HttpURLConnection? = null
         try {
             connection =