Package the Windows client in CI, on the runner that could not

The build job published a win-x64 tree and stopped there, so the half of a
release that fails in ways a compile cannot see was proved by nobody until a
person was midway through cutting one. It now packs as well: vpk opens the
published binaries and verifies the main executable really calls
VelopackApp.Build().Run(), which is the check worth having — a refactor that
drops that call compiles, tests green, and produces an application that silently
never updates itself.

The file said this was impossible on Linux, and also said it was fine, in
comments forty lines apart. The claim that vpk needs Windows tooling to stamp the
Setup.exe stub is the one that was wrong: vpk cross-compiles when told to, and
the telling is a bracketed directive before the verb rather than a flag. Plain
`vpk pack --runtime win-x64` on a Linux host refuses outright and says so in the
message that names the fix. `[win]` must be quoted, or the shell reads it as a
glob matching any one of w, i and n. Only signing needs Windows, and nothing here
is signed yet.

Fixing that does not move ADR 0013 rule 3 an inch, which is why the two reasons
were recorded separately in the first place. What may not live on a runner is the
token, not the build: Velopack clients apply what their feed serves without
verifying a signature, so whoever can write a release can ship an update every
install runs. The packages go to RUNNER_TEMP and die with the job. They are not
offered as workflow artefacts either — an installer nobody has run should not sit
somewhere that invites passing it on.

Written out as shell rather than by calling scripts/release-windows.ps1. That
script is a person's procedure and holds things a runner must not have and must
not skip: it refuses a dirty tree, insists HEAD is tagged, downloads the previous
release for deltas, and asks for the forge token. Calling it would mean either
weakening it with CI switches or having CI satisfy conditions that only make
sense at a desk. The constants the two now share — pack id, title, authors,
channel, icon — are a contract with VelopackUpdateChannel and with every
installed client, and both sides say so.

Two things fell out of running the steps rather than reading them, and both were
in code nothing had ever executed:

dotnet msbuild -getProperty:Version answers 1.0.0. Without a target named it
evaluates the project and runs nothing, and MinVer computes inside a target — so
the read comes back as the SDK default on a full checkout with every tag present.
That line is the tag check in this file, which is `if:` a tag ref, and there are
no tags yet: the first release ever cut would have been refused by its own guard,
which would then have blamed fetch-depth. release-windows.ps1 had the same line
and would have demanded HEAD be tagged v1.0.0. Both now pass -t:MinVer.

And MinVer answers 0.0.0-alpha.0.N until that first tag exists, which vpk rejects
outright as below 0.0.1 — so packing the true version could not have worked on
any build made today. The patch digit is lifted for the throwaway package only.
The release script gets no such floor and must not: its version is the one users
compare against, and there the refusal is the right outcome.

Verified by extracting both steps from this file and running them against a real
clone in a dotnet SDK container: Setup.exe, the portable zip, the .nupkg and
releases.win.json, from a machine that is not Windows.

docs/adr/0013-desktop-distribution-and-updates.md

@@ -85,13 +85,38 @@ packs and stops. Phase two, a separate invocation, asks for the token and upload
 what reaches users has been installed and started by a human first, and so that the credential is in memory
 only for the minutes that need it.
 
-There is a second, smaller reason the release could not be a CI job here anyway: `vpk` stamps and embeds
-the `Setup.exe` and `Update.exe` stubs with Windows tooling, and every job in `ci.yml` is
-`runs-on: [linux]`. Both reasons are recorded because somebody will fix one and believe they are done.
+A second, smaller reason was recorded here — that `vpk` stamps and embeds the `Setup.exe` and
+`Update.exe` stubs with Windows tooling, and every job in `ci.yml` is `runs-on: [linux]` — on the
+reasoning that somebody will fix one reason and believe they are done.
 
-What CI does gain is the same thing the `android` job already does — it proves the artefact still builds.
-A `win-x64` publish runs on main and on tags, so a restore graph that resolves for `net10.0` and not for
-`net10.0/win-x64` fails there rather than under a person midway through a release.
+◆ **That second reason was not true, and the correction is worth more than the claim was.** `vpk`
+cross-compiles when it is told to: the bracketed OS directive, `vpk [win] pack`, builds the setup stub,
+the portable bundle and the `.nupkg` on Linux, and reports `Directive enabled for cross-compiling from
+Linux (current os) to Windows` while doing it. Only signing needs Windows tooling, and rule 8 above is
+why nothing is signed yet. Plain `vpk pack` on Linux targets Linux and rejects a Windows RID, which is
+the shape of the mistake: the tool does not fail because it cannot, it fails because it was not asked.
+
+The correction does not move this rule at all, and that is the point of separating the two. The reason
+that stands was never mechanical, so a Linux runner that *can* pack changes nothing: what may not be on
+a runner is the token, not the build.
+
+What CI gains is the same thing the `android` job already does — it proves the artefact still builds and
+still packages. On main and on tags the build job publishes `win-x64` and then packs it, so a restore
+graph that resolves for `net10.0` and not for `net10.0/win-x64` fails there rather than under a person
+midway through a release. Packaging is the more valuable half and adds a few seconds to a publish that
+has already happened — measured at two to seven, against the minutes the publish itself takes: `vpk` verifies
+that the main executable actually calls `VelopackApp.Build().Run()`, so the change that quietly produces
+an application which never updates itself — compiling, tested, and invisible until a release goes
+unreceived — fails in CI. The packages are written to `RUNNER_TEMP` and discarded, and are deliberately
+not offered as workflow artefacts: an installer nobody has run should not sit somewhere that invites
+passing it on.
+
+CI does not call `scripts/release-windows.ps1` to do any of this, and should not. That script is the
+person's procedure — it refuses a dirty tree, requires a tagged `HEAD`, fetches the previous release for
+deltas, and prompts for the token — so running it on a runner would mean either weakening it with CI
+switches or having CI satisfy conditions that only make sense at a desk. The workflow writes the same
+`vpk` arguments out in shell, and the constants they share (pack id, title, authors, channel, icon) are
+noted in both places as a contract with `VelopackUpdateChannel` and with every installed client.
 
 ### 4. The update check points at the project's forge, and the address is a constant