Add Kotlin/JVM target (`--to kotlin`) + Kotlin tdbin runtime — the JVM is the only major ecosystem missing

[MelbourneDeveloper]

Problem

typediagram --help lists the code generation targets:

LANG is one of: typescript|python|typeshed|rust|go|csharp|fsharp|dart|protobuf|php

There is no Kotlin/JVM target. That is a gap for anyone shipping an IntelliJ-platform plugin, an Android client, or a Spring service against a typeDiagram schema — the JVM is a first-tier ecosystem and it is the only major one missing from that list.

Concretely: Deslop ships a JetBrains plugin (clients/jetbrains, Kotlin + Gradle) alongside its VS Code extension. Both consume the same .td schema. The VS Code side gets generated types; the JetBrains side has to hand-roll kotlinx.serialization JSON parsing against a schema it cannot generate from:

// clients/jetbrains/deslop-shared/src/main/kotlin/…/DeslopOffenderGrouping.kt
import kotlinx.serialization.json.Json
import kotlinx.serialization.json.JsonObject
import kotlinx.serialization.json.JsonPrimitive
…

Hand-written wire models drift from the schema by construction. Our own repo policy forbids hand-written wire structs, and the JVM client is the one place we cannot honour it.

Ask

1. --to kotlin

Emit @Serializable data class records and sealed interface + @Serializable variant classes for unions, targeting kotlinx.serialization (the de-facto standard on both Android and the IntelliJ platform).

Mapping we would expect:

typeDiagram	Kotlin
Int	Long
Float	Double
Bool	Boolean
String	String
Option<T>	T? with @EncodeDefault(NEVER) semantics
List<T>	List<T>
type	@Serializable data class
union with bare variants	enum class or sealed objects
union with payload variants	sealed interface + @Serializable data class per variant, @SerialName pinned to the DSL variant name

Note the payload-variant requirement specifically — see #40, where --to csharp collapses payload-carrying unions to a flat enum and loses data. Kotlin's sealed hierarchies model these natively, so please do not repeat that shape.

2. Kotlin tdbin runtime

Once #1 exists, the JVM end needs a tdbin codec too, or the JetBrains plugin stays on JSON while the rest of the fleet moves to binary. Same asks as the TypeScript codec: list support, scalar Option<T> presence bits, lossless 64-bit integers (trivial on the JVM — Long is already exact), schema-hash validation, and Rust↔Kotlin golden-vector conformance tests.

Kotlin is arguably the easiest tdbin target after Rust: Long is exact, ByteBuffer/ByteArray give direct little-endian word access with no DataView gymnastics, and there is no bundle-size constraint.

Priority note

--to kotlin (part 1) has standalone value and is worth landing on its own — it fixes hand-maintained JVM DTOs for every consumer, independent of whether tdbin ever ships. The tdbin codec (part 2) is only useful once the runtime is published and the schema actually verifies.