Document publishing the installer as a release asset

The exe is attached to a release, never committed: most forges reject files over
100 MB inside a repository while allowing release assets far larger, and a
committed binary would sit in every future clone forever.

Also records that tags must be pushed explicitly. A plain push of the branch
does not carry them, so a release had nothing to hang off.

docs/RELEASING-WINDOWS.md

@@ -150,6 +150,17 @@ Alongside the `.exe`, publish:
 - release notes covering what changed and anything needing attention;
 - the version in the filename, so a server's build is identifiable on sight.
 
+The installer is attached to a git-forge release as an ASSET, never committed.
+Most forges reject files over 100 MB inside a repository while allowing release
+assets far larger, and a committed binary would sit in every future clone
+forever. Release creation is scripted next to the other deployment scripts and
+verifies the SHA-256 before publishing, because a truncated upload is easiest to
+catch before anyone can download it.
+
+Tags have to reach the forge for a release to hang off one: a plain
+`git push <remote> main` does not carry them, which is why the push step uses
+`--follow-tags`.
+
 The compiled installer stages a CycloneDX inventory (`sbom.cdx.json`) onto every
 server, which is what answers a security question about a published
 vulnerability without anyone guessing.