fix(publish): Windows owns the root metadata modules — 0.1.15 roots had no mingwX64 variants

The KotlinMultiplatform (root) publications ran on the macOS job, and a
macOS host never declares the mingwX64 target (vHostSupportsMingw) — so
every published root .module carried variants for linux/macos/jvm but
NOT mingw_x64. Windows consumers of the bridge resolved the root fine
and then found 'No matching variant' for every coordinate: v0.1.15 (and
every earlier release) is unusable from the published root modules on
Windows. Local mavenLocal flows never caught it because this repo's dev
box IS Windows, whose roots include all targets.

Two changes:
- createRenderBackend / rendererPreferredGpuMode become a real
  expect/actual seam (:ui nativeMain expect, actuals in each renderer
  source set). They were duplicate no-expect declarations — fine
  per-target, but shared nativeMain METADATA couldn't see them when a
  host's targets span both renderers, which is exactly what blocked
  :window's metadata compilation on Windows hosts.
- The publish workflow moves the KotlinMultiplatform + Jvm + bridge
  plugin publications to the WINDOWS job (the only host declaring every
  target) and updates the delete-then-retry ownership map to match.

Verified on Windows: repo-wide common+native metadata sweep green for
all library modules, full publishKotlinMultiplatformPublicationToMavenLocal
(root .module variants now cover linux_x64/linux_arm64/macos_arm64/
mingw_x64/jvm), demo links + boots, and the bubble-wrap consumer example
resolves and links mingwX64 through the bridge against the local roots.

.github/workflows/publish.yml

@@ -18,9 +18,8 @@ jobs:
     strategy:
       fail-fast: false
       # Each host runs only the publish tasks Gradle actually generated for it.
-      # macOS also publishes the shared kotlinMultiplatform metadata module.
+      # WINDOWS also publishes the shared kotlinMultiplatform metadata modules
-      # No library module declares jvm() today — apps do their own JVM parity
+      # (see its matrix entry) + the jvm jar + the bridge plugin.
-      # build against upstream Compose, so JVM isn't part of the publication.
       # `target` is the Gradle K/N target token (Capitalised) — one per host,
       # used for :demo / :apidemo linkReleaseExecutable<Target>. linuxArm64 is
       # skipped for the app build because SDL3 static libs on the ubuntu runner
@@ -31,16 +30,8 @@ jobs:
             host: macos
             target: MacosArm64
             exe_ext: kexe
-            # jvm publication: only :material-symbols declares a jvm() target
-            # (its common API renders via upstream Compose on JVM) — publish
-            # its host-independent jar from the same host as the metadata.
-            # :compose-desktop-native-bridge (the consumer-side bridge Gradle plugin +
-            # its plugin marker) is host-independent too — same job.
             tasks: >-
-              publishKotlinMultiplatformPublicationToGitHubPackagesRepository
               publishMacosArm64PublicationToGitHubPackagesRepository
-              publishJvmPublicationToGitHubPackagesRepository
-              :compose-desktop-native-bridge:publishAllPublicationsToGitHubPackagesRepository
           - runner: ubuntu-22.04
             host: linux
             target: LinuxX64
@@ -52,8 +43,18 @@ jobs:
             host: windows
             target: MingwX64
             exe_ext: exe
+            # WINDOWS owns the root KotlinMultiplatform metadata modules: it is
+            # the ONLY host that declares every target (vHostSupportsMingw is
+            # host-gated), so only its generated .module files carry the full
+            # variant table — the macOS-published roots of v0.1.15 had NO
+            # mingwX64 variants and Windows consumers could not resolve them.
+            # The host-independent jvm jar (:material-symbols) and the bridge
+            # plugin ride along on the same job.
             tasks: >-
               publishMingwX64PublicationToGitHubPackagesRepository
+              publishKotlinMultiplatformPublicationToGitHubPackagesRepository
+              publishJvmPublicationToGitHubPackagesRepository
+              :compose-desktop-native-bridge:publishAllPublicationsToGitHubPackagesRepository
 
     runs-on: ${{ matrix.runner }}
 
@@ -148,8 +149,8 @@ jobs:
       # already completed; you can't tell from the 409 alone. The fix: between
       # attempts, DELETE this host's package versions for the current release
       # and re-upload from a clean slate. Each host owns DISJOINT package
-      # names (roots / -macosarm64 / -jvm / bridge on macOS, -mingwx64 on
+      # names (roots / -mingwx64 / -jvm / bridge on Windows, -macosarm64 on
-      # Windows, -linuxx64/-linuxarm64 on Linux), so parallel jobs never touch
+      # macOS, -linuxx64/-linuxarm64 on Linux), so parallel jobs never touch
       # each other's uploads. Uses the run's GITHUB_TOKEN (packages: write);
       # a 403 on delete just degrades to the old blind-retry behaviour.
       - name: Publish to GitHub Packages
@@ -161,9 +162,9 @@ jobs:
           # Keep in sync with the module list in settings.gradle.kts.
           MODULES="ui ui-util ui-geometry ui-unit ui-backhandler ui-tooling-preview animation animation-core animation-graphics foundation foundation-layout material3 material-ripple window material-symbols navigation3-ui components-resources"
           case "${{ matrix.host }}" in
-            macos)   SUFFIXES="_ROOT_ -macosarm64" ;;
+            macos)   SUFFIXES="-macosarm64" ;;
             linux)   SUFFIXES="-linuxx64 -linuxarm64" ;;
-            windows) SUFFIXES="-mingwx64" ;;
+            windows) SUFFIXES="_ROOT_ -mingwx64" ;;
           esac
           host_packages() {
             for m in $MODULES; do
@@ -171,7 +172,7 @@ jobs:
                 if [ "$s" = "_ROOT_" ]; then echo "com.bitsycore.compose.sdl.$m"; else echo "com.bitsycore.compose.sdl.$m$s"; fi
               done
             done
-            if [ "${{ matrix.host }}" = "macos" ]; then
+            if [ "${{ matrix.host }}" = "windows" ]; then
               echo "com.bitsycore.compose.sdl.material-symbols-jvm"
               echo "com.bitsycore.compose.sdl.compose-desktop-native-bridge"
               echo "com.bitsycore.compose-desktop-native.bridge.com.bitsycore.compose-desktop-native.bridge.gradle.plugin"

CLAUDE.md

@@ -275,11 +275,15 @@ commonMain
                    attached to: mingwX64Main always; macOS/Linux when -Prenderer=sdl3.
 ```
 
-`createRenderBackend(…)` + `rendererPreferredGpuMode()` are declared identically
+`createRenderBackend(…)` + `rendererPreferredGpuMode()` are `expect`s in
-in both `skikoRendererMain` and `sdlRendererMain`. `:window` calls them straight
+`:ui`'s nativeMain with `actual`s in BOTH `skikoRendererMain` and
-from `:ui` — no `expect`/`actual`, no factory layer — and the right impl
+`sdlRendererMain` — unambiguous because **only one of the two renderer source
-resolves because **only one of the two renderer source sets is attached to a
+sets is attached to a given target**. (They used to be plain duplicate
-given target**. Under `-Prenderer=sdl3`, the `skikoRenderer*` source sets are
+declarations with no expect; that compiled per-target but shared nativeMain
+METADATA couldn't see them on a host whose targets span both renderers, which
+blocked the WINDOWS host from producing :window's KotlinMultiplatform
+publication — and Windows must publish the root modules, see the publish
+workflow.) Under `-Prenderer=sdl3`, the `skikoRenderer*` source sets are
 **not even created**, so Gradle has nothing to warn about and Skiko is never
 pulled in.
 
@@ -512,7 +516,10 @@ that should surface in tooling.
   'Color'` / `Cannot access class ...` in `compileCommonMainKotlinMetadata`,
   while per-target compilation is fine). Declare EVERY artifact the common
   code touches DIRECTLY (ui-graphics, ui-text, ui-unit, …) and give each its
-  own bridge rule. Note only the macOS publish job compiles common metadata —
+  own bridge rule. Note only the WINDOWS publish job compiles common metadata
+  (it owns the root KotlinMultiplatform publications — the only host that
+  declares every target, so only its .module files carry the full variant
+  table; macOS-published roots left v0.1.15 without mingwX64 variants) —
   test with `gradlew :<module>:compileCommonMainKotlinMetadata` before tagging.
 - **`Path()` in commonMain returns different actuals per renderer** —
   the Skia renderer produces a `SkiaBackedPath` (wraps

compose/ui/ui/src/nativeMain/kotlin/com/compose/sdl/RenderBackendFactory.kt

@@ -0,0 +1,24 @@
+package com.compose.sdl
+
+// ==================
+// MARK: Renderer entry points (expect)
+// ==================
+
+/* The renderer seam :window builds against. Each renderer source set
+   (skikoRendererMain / sdlRendererMain) supplies the actuals; exactly one of
+   the two is attached to any given target, so resolution stays unambiguous.
+
+   These were originally declared identically in both renderer source sets
+   with NO expect — fine per-target, but shared nativeMain METADATA (=: what
+   :window's KotlinMultiplatform publication compiles against) could not see
+   them on a host where the attached targets span BOTH renderers (Windows:
+   skikoRenderer for macos/linux + sdlRenderer for mingw). The expect makes
+   nativeMain metadata self-contained, which lets the WINDOWS publish job —
+   the only host that declares every target — produce the root modules. */
+
+/* Create the render backend for the selected [GpuMode]; null when the
+   backend can't initialise (caller falls back / reports). */
+expect fun createRenderBackend(inSdl: SDL3Backend, inGpu: GpuMode): RenderBackend?
+
+/* The renderer module's per-OS default GpuMode (used for GpuMode.Auto). */
+expect fun rendererPreferredGpuMode(): GpuMode

compose/ui/ui/src/sdlRendererMain/kotlin/com/compose/sdl/PlatformGpu.kt

@@ -6,7 +6,7 @@ import kotlin.experimental.ExperimentalNativeApi
 // MARK: SDL3 renderer per-OS default
 // ==================
 
-fun rendererPreferredGpuMode(): GpuMode {
+actual fun rendererPreferredGpuMode(): GpuMode {
     @OptIn(ExperimentalNativeApi::class)
     return when (Platform.osFamily) {
         OsFamily.MACOSX -> GpuMode.Sdl3.Metal

compose/ui/ui/src/sdlRendererMain/kotlin/com/compose/sdl/RenderBackendFactory.sdl.kt

@@ -11,7 +11,7 @@ import com.compose.sdl.renderer.sdl.Sdl3RenderBackend
    renderer modules expose createRenderBackend / rendererPreferredGpuMode
    with identical signatures in this package, and the build includes exactly
    one of them per target. Rejects Skia.* since this module has no Skiko. */
-fun createRenderBackend(inSdl: SDL3Backend, inGpu: GpuMode): RenderBackend? {
+actual fun createRenderBackend(inSdl: SDL3Backend, inGpu: GpuMode): RenderBackend? {
 	val vResolved = if (inGpu is GpuMode.Auto) rendererPreferredGpuMode() else inGpu
 	if (vResolved is GpuMode.Skia) {
 		error("$vResolved isn't available in this build — Skiko isn't linked. " +

compose/ui/ui/src/skikoRendererMain/kotlin/com/compose/sdl/PlatformGpu.kt

@@ -9,7 +9,7 @@ import kotlin.experimental.ExperimentalNativeApi
 
 internal expect fun makeMetalBridge(backend: SDL3Backend): SkiaBridge?
 
-fun rendererPreferredGpuMode(): GpuMode {
+actual fun rendererPreferredGpuMode(): GpuMode {
     @OptIn(ExperimentalNativeApi::class)
     return when (Platform.osFamily) {
         OsFamily.MACOSX -> GpuMode.Skia.Metal

compose/ui/ui/src/skikoRendererMain/kotlin/com/compose/sdl/RenderBackendFactory.skia.kt

@@ -11,7 +11,7 @@ import com.compose.sdl.renderer.skia.SkiaRenderBackend
    SDL3 module's createRenderBackend / rendererPreferredGpuMode in the same
    package; exactly one renderer module is included per target. Rejects
    Sdl3.* since this module has no SDL3_ttf / SDL3_image. */
-fun createRenderBackend(inSdl: SDL3Backend, inGpu: GpuMode): RenderBackend? {
+actual fun createRenderBackend(inSdl: SDL3Backend, inGpu: GpuMode): RenderBackend? {
 	val vResolved = if (inGpu is GpuMode.Auto) rendererPreferredGpuMode() else inGpu
 	if (vResolved is GpuMode.Sdl3) {
 		error("Sdl3.* modes aren't available in a Skia build — rerun with -Prenderer=sdl3")