docs: surface build-unity-image custom image flow

docs/08-docker/01-docker-images.mdx

@@ -14,6 +14,10 @@ Images for newly released Unity editor versions are added almost immediately to
 [`game-ci/docker`](https://github.com/game-ci/docker/) . This process is automated, please allow a
 few hours.
 
+If you need a Unity editor image with multiple build modules installed together, use the
+[`game-ci build-unity-image` CLI command](/docs/docker/custom-images). It generates images from the
+same Docker build logic that GameCI uses for the published `unityci/editor` images.
+
 ## Features
 
 - All editor versions

docs/08-docker/03-customize-docker-images.mdx

@@ -6,6 +6,11 @@ with blender assets. Sometimes, you'll need some specific command lines or runti
 unity in a _postprocess_ step. This documentation will guide you into building your own images on
 top of the existing ones to add your desired tools.
 
+If you only need multiple Unity modules in one editor image, prefer
+[`game-ci build-unity-image`](/docs/docker/custom-images) instead of maintaining a custom
+Dockerfile. Keep this guide for extra operating-system tools or project-specific dependencies that
+are not part of Unity's module installer.
+
 ## Example: Add Ruby to existing images
 
 In the following example, we will be adding `Ruby` on top of the existing docker images (all unity

docs/08-docker/05-custom-images.mdx

@@ -25,6 +25,10 @@ game-ci build-unity-image ubuntu windows-mono,linux-il2cpp \
   --unity-version 2022.3.20f1 \
   --tag ghcr.io/my-org/unity-editor:desktop \
   --push
+
+# Build a Windows-based editor image
+game-ci build-unity-image windows windows-mono,mac-mono \
+  --unity-version 2022.3.20f1
 ```
 
 ## Usage
@@ -51,6 +55,9 @@ game-ci build-unity-image [baseOs] [modules] [options]
 | `--hub-image`     | `unityci/hub`      | Hub base image                            |
 | `--base-image`    | `unityci/base`     | Editor base image                         |
 
+The CLI also supports `baseOs=windows`. When you select `windows`, the command uses the Windows
+Hub and base image defaults unless you override them with `--hub-image` and `--base-image`.
+
 ### Available Modules
 
 | Module         | Description                       |
@@ -65,9 +72,11 @@ game-ci build-unity-image [baseOs] [modules] [options]
 
 ## GitHub Actions Example
 
-### On-the-fly (with caching)
+### Build-and-use locally (no registry needed)
 
-Build the image as a CI step. Docker layer caching makes subsequent runs fast:
+Most projects don't need to publish their Unity editor image — build it as a CI step, tag
+it locally, and reference that local tag in the same job. The image lives only in the
+runner's Docker daemon for the lifetime of the job:
 
 ```yaml
 jobs:
@@ -91,9 +100,30 @@ jobs:
           targetPlatform: StandaloneWindows64
 ```
 
+No GHCR account, no `docker login`, no pushed bytes. The image never leaves the runner.
+
+#### Build cost and caching
+
+The CLI invokes `docker build` directly. Image build time is dominated by Unity Hub
+installing the editor and modules — expect 15-30 minutes for typical desktop combos. On
+GitHub-hosted runners that work is repeated every job because the runner (and its Docker
+daemon) is destroyed at the end of each run.
+
+If that rebuild cost is acceptable for your cadence, you're done. Otherwise pick one of:
+
+| Strategy                       | What you set up                                                                | Best for                                         |
+| ------------------------------ | ------------------------------------------------------------------------------ | ------------------------------------------------ |
+| **Self-hosted runner**         | A persistent runner whose Docker daemon retains layers between jobs            | Teams already running self-hosted infrastructure |
+| **Push once, pull thereafter** | Build the image in a scheduled workflow, push to GHCR, pull in build workflows | Stable module combos used by many runs           |
+| **Buildx + GHA cache backend** | Wrap the build with `docker/setup-buildx-action` and a cache-aware build step  | Frequent module/version churn on hosted runners  |
+
+The push-once strategy is covered below. For self-hosted runner caching, see the
+[orchestrator caching guide](/docs/github-orchestrator/advanced-topics/caching).
+
 ### Pre-built (push once, pull forever)
 
-Build and push the image to a registry once, then reference it in all builds:
+When the same image is used across many workflows, repos, or runs, push it to a registry
+once and reference it everywhere:
 
 ```yaml
 # Run once (or on a schedule)
@@ -133,6 +163,7 @@ Then in your build workflow:
 | Name              | Modules                              | Use case                         |
 | ----------------- | ------------------------------------ | -------------------------------- |
 | Desktop           | `windows-mono,linux-il2cpp,mac-mono` | Wwise/FMOD, Steam multi-platform |
+| Windows desktop   | `windows-mono,mac-mono`              | Windows-hosted plugin workflows  |
 | Desktop + Android | `windows-mono,linux-il2cpp,android`  | Meta Quest + PC VR               |
 | Mobile            | `android,ios`                        | Multi-platform mobile            |