0.12.0 Palianytsia

• Baton and Apollo Kotlin end to end on a phone: kotlin/samples/apollo-android,
  the Android sample's twin over Apollo Kotlin 5.2.0 and its memory and SQL
  caches, and kotlin/benchmarks/macro, a Macrobenchmark module that drives
  both release builds against a fixed server in each app's process. On a
  Google Pixel 9, a cold start over the data on disk shows the list in
  240 ms, in the first frame, against Apollo's 272 ms after a spinner; a
  tap to a detail takes 22 ms against 33 ms; scrolling is the same in both.
  From the response's first byte to the list's frame Apollo is faster,
  42 ms against 58 ms. The Android sample's release build is signed with
  the debug key, its screens report their first draws, and a launch can
  ask for the fixed server.
• Apollo Kotlin measured beside Baton, kotlin/benchmarks/apollo-comparison:
  the same operation and graph through Apollo Kotlin 5.2.0 and its
  normalized cache 1.0.9, configured as documented, on the JVM and on a
  Google Pixel 9 in a release build. On the phone the response is in
  Baton's store in 6.5 ms and in Apollo's in 44.6 ms, and Apollo's read of
  the query back takes 25 ms where Baton's availability check takes 1.2 ms;
  a field of Apollo's read model costs 2 ns against 43 ns for a lens read.
  docs/comparison.md quotes these in place of Apollo's own bench.
• The Kotlin runtime's first numbers on a device, in BENCHMARKS.md: on a
  Google Pixel 9 running Android 17, the 899-record fixture tokenizes in
  19.0 ms off the main thread and commits in 6.7 ms on it, a debuggable
  device-test build, and in 5.1 ms and 1.3 ms from a release build that is
  not debuggable, kotlin/benchmarks/android, the medians of 300 runs;
  the native-runtimes record carries the number as the ingest budget's
  first evidence.
• The desktop sample keeps its page bar through a failure, so a page the
  public API refused (HTTP 429, Cloudflare's 1015 under a burst) can be
  left or retried; caches avatars for the process; keys its rows by
  recordID; keeps the store's image under the schema's digest, so a
  relaunch shows the characters before the network answers; and draws its
  screens to PNG files without a window through
  gradle :samples:desktop:screenshot.
• A second Kotlin sample, kotlin/samples/github, the Compose for Desktop
  twin of examples/GitHubTriage: sign-in with a token kept in memory, a
  repository with a star toggle whose optimistic response flips the star and
  the count, its open issues as a connection that loads the next page at
  the list's end, an issue whose composer appends an optimistic comment by
  the viewer through @appendEdge, and sign-out that ends the environment
  and removes the image. Its tests run the screens over ScriptedTransport.
• A Kotlin operation's companion is a QueryType, MutationType or
  SubscriptionType naming the operation's class beside its data, so
  val rename = rememberMutation(RenameMutation) infers its action's type.
  OperationType and the three are application API, outside the
  baton.Generated opt-in that an app's call to rememberMutation failed
  before; what generated code alone calls on them stays inside it.
• @Fragment, @Query, @Mutation and @Subscription repeat in Kotlin,
  so one composable can host several documents, as a button that stars and
  unstars hosts two mutations.
• The Kotlin Retention is Hold (handle.retain(): Hold,
  hold.release()), since baton.Retention hid
  kotlin.annotation.Retention from every file that writes
  import baton.*. Swift keeps Retention.
• Phase, Fetch and MutationAction are @Stable in Kotlin, so a
  composable handed a failed phase skips like any other. The Compose
  compiler's reports, turned on with -PcomposeReports=true, show every
  generated lens and LensList stable and every composable of the desktop
  sample restartable and skippable.
• baton-inspector, the Kotlin store inspector: StoreInspector(environment),
  a live, searchable Compose view of the store's records by type with their
  fields, values and field errors, and StoreExport.text(store), the dump.
  The desktop sample shows it in a third pane from its View menu
  (Command-I), and follows the system's light or dark appearance.
• The Kotlin runtime builds for Android (API 23 and up): the image on the
  system's SQLite through AndroidSQLiteDriver, HttpTransport and
  Environment(url) shared with the JVM, and
  Persistence.named(name, directory = cacheDir.path), since the runtime
  holds no Context. baton-inspector builds for Android too; the
  desktop sample's screens moved to kotlin/samples/shared, which
  kotlin/samples/android, a phone app, shows as well; and
  IngestBenchmark, a device test, logs the Fixture's ingest and commit
  medians with the device's model for the ingest budget.