Take ktfmt's defaults for the Kotlin half

The server half went to rustfmt's defaults earlier today; this is the same
move for the app, and the same reasoning. Kotlin ships no formatter with
the Gradle build, so the question was which to adopt: ktfmt is Kotlin-org
owned now (it moved from facebook/ktfmt), is a formatter rather than a
configurable linter, and has essentially nothing to tune -- which is what
rule 27 is asking for. ktlint's .editorconfig surface is the thing that
rule warns against, and detekt is static analysis, whose job Android Lint
already does here.

One setting, and it is a choice between the tool's own two styles rather
than a tuning: kotlinLangStyle() is the 4-space one, which is what this
code already was. The 2-space default would have reindented every file to
say nothing.

  ./gradlew :androidApp:ktfmtFormat   to apply
  ./gradlew :androidApp:ktfmtCheck    to verify

Formatting only. The one thing worth checking by hand was the generated
PEM constant, since a leading newline there costs Android's
CertificateFactory its preamble sniff and fails at runtime nowhere near
the cause: ktfmt moved `.trimMargin()` onto its own line and left the
template alone, and the regenerated constant still starts at the opening
quotes.

Verified after: ktfmtCheck, compileDebugKotlin and lintDebug all pass, and
the APK builds.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017xn8nHw1tw1R6PtiY1eEtw

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

@@ -5,15 +5,13 @@ import java.net.HttpURLConnection
 import java.net.URL
 
 /**
- * The SSE half of the API: one long-lived GET per open session screen,
- * replaying the transcript after a cursor and then following it live.
+ * The SSE half of the API: one long-lived GET per open session screen, replaying the transcript
+ * after a cursor and then following it live.
  *
- * 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; run() then returns instead of throwing, so a
- * deliberate close doesn't surface as a connection error. The caller owns
- * reconnecting (with the last seq it saw as the new cursor) -- see
- * SessionScreen.
+ * 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; run() then returns instead
+ * of throwing, so a deliberate close doesn't surface as a connection error. The caller owns
+ * reconnecting (with the last seq it saw as the new cursor) -- see SessionScreen.
  */
 class EventStream(private val settings: ServerSettings, private val sessionId: String) {
     @Volatile private var connection: HttpURLConnection? = null