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

@@ -19,19 +19,15 @@ import androidx.compose.ui.platform.LocalContext
  * The point of splitting it up is that "the scroll is laggy" has two completely different causes
  * and one appearance. If the layout-and-measure and draw figures are small and the total is large,
  * the time is going into rasterising and compositing, and no amount of doing less work per row will
- * move it. If they are large, the work per row is the problem and it is ours to fix. Guessing
- * between those two is how a day gets spent rewriting the half that was already fast.
+ * move it. If they are large, the work per row is the problem and it is ours to fix.
  *
  * The phases are the platform's own: [FrameMetrics] reports each frame's cost in nanoseconds,
- * broken down into the parts the UI thread is responsible for -- handling input, running
- * animations, measuring and laying out, recording the draw -- and the parts after it.
+ * broken into the parts the UI thread is responsible for and the parts after it.
  *
  * One of these for the app, like [DebugStats], because the two are read as one report and
  * [drawAccounting] divides one by the other. Held per screen it was emptied by leaving a session
  * and the counters were not, so a report copied after visiting two sessions divided every session's
- * work by the newest one's frame count -- and printed the result as a per-frame measurement. It
- * said 36.8 seconds of placement inside a 13.5 second window, and left "everything else" clamped at
- * 0.00ms (0%), which reads as a screen whose whole cost is this app's own code.
+ * work by the newest one's frame count -- 36.8 seconds of placement inside a 13.5 second window.
  */
 object FrameStats {
     private val total = ArrayList<Long>()
@@ -54,7 +50,7 @@ object FrameStats {
         total += metrics.getMetric(FrameMetrics.TOTAL_DURATION)
         // How long the frame waited for the UI thread to be free before it could start. Reported
         // because the phases otherwise do not add up to the total, and the gap is the interesting
-        // part: it is the frame being held up by work that is not the frame's.
+        // part: the frame being held up by work that is not the frame's.
         waited += metrics.getMetric(FrameMetrics.UNKNOWN_DELAY_DURATION)
         input += metrics.getMetric(FrameMetrics.INPUT_HANDLING_DURATION)
         animation += metrics.getMetric(FrameMetrics.ANIMATION_DURATION)
@@ -123,7 +119,7 @@ private const val CAP = 20_000
  * Records into [FrameStats] for as long as this screen is on it.
  *
  * The listener is what comes and goes; what it writes into does not, so a report covers the same
- * stretch of time as the counters beside it. See [FrameStats].
+ * stretch of time as the counters beside it.
  *
  * The listener is handed its own thread because the platform calls it for every frame and the
  * documentation is explicit that doing that on the main thread taxes the very thing being measured.