Build the Windows installer in CI

The fourth leg of build-and-test.yml, in the shape of the Android one:
an image workflow that builds docker/windows and pushes it tagged by
the directory's tree id, and a job inside that image that lints the
Windows target — the only place the cfg(windows) branches are ever
compiled by CI — builds, runs the smoke tests docs/windows.md §6
specifies, packages, installs and uninstalls under Wine, and uploads
the installer. Every step was run by hand in the same container first.

The spec's open list closes with this: the four §3.2 items, the
licence page, and the leg. What remains is what Wine cannot show, and
§10 now lists it as the first real Windows run's checklist.

docker/windows/README.md

@@ -45,12 +45,17 @@ Measured on the first build, 2026-09-12:
 | `wine uninstall.exe /S` | Removes the directory and the key |
 | Start Menu shortcut | **Not verifiable here.** `CreateShortcut` is `IShellLink` and does nothing under a headless Wine; the directory beside it is created. Check on Windows. |
 
-None of this proves a Vulkan device opens, a render completes, fonts are found or the secret store
-round-trips. Those are a Windows machine, once per release — and today the secret store *cannot*
-round-trip, because its Windows implementation is still the loud placeholder (docs/windows.md
-§3.2).
+Also checked by running the application itself under Wine: its log lands in
+`AppData\Local\darkroom\state`, and nothing is written outside `AppData` (FR-PLAT-WIN-1).
+
+None of this proves a Vulkan device opens, a render completes, fonts are found, the secret store
+round-trips or the browser opens for sign-in. Those are a Windows machine, once per release.
 
 ## In CI
 
-Not yet wired. The image and the leg are specified in docs/windows.md §7 in the shape of the
-Android ones, and every step they would run has been exercised by hand above.
+`.gitea/workflows/windows-image.yml` builds this image and pushes it to
+`gitea.tourolle.paris/dtourolle/darkroom-windows`, exactly as the Android image is handled — tagged
+by the tree hash of `docker/windows/`, rebuilt when and only when a file here changes. The
+`windows` job in `build-and-test.yml` then runs, inside it, the same commands listed above plus
+`cargo clippy --target x86_64-pc-windows-gnu -- -D warnings`, and uploads the installer as an
+artefact.