Give the Windows app a page, and give the app a version to report

[peopleworks]

Closes nothing — this came from a support message, not an issue.

What happened

Somebody reported that "desktop 0.4.0 is not published". Two true things sat behind that
sentence and neither was the one they said.

The download path was a GitHub search URL. The only route to the Windows app was
/releases?q=desktop&expanded=true, reachable from the notice on /batch — a wall of tags and
checksums for somebody whose question was "how do I open my PDFs". Half of the desktop app's
reason to exist was invisible to every web visitor.

The app never said which build it was. The title bar carried its name and nothing else, so
neither the user nor anybody helping them could tell 0.3.0 from 0.4.0.

What this does

• /download, bilingual: the four things the window can do that a tab cannot, each stated
  against what the browser does instead; what it does not change (same engine, same numbers, and
  the exact privacy wording from the README, not a wider one); and that Windows will warn about the
  unsigned build, with the steps to check the file instead of clicking through the warning.
• The same page on the desktop host answers the opposite question — which build you are running,
  and whether a newer one is published. Nothing auto-updates: an unsigned app that downloads and
  runs code on its own is the behaviour we would tell a teacher to be suspicious of.
• A nav link, only where a folder cannot be opened. Same signal, same reason, as the folder link
  beside it. /batch points here instead of at GitHub.
• The footer prints the version on the desktop, and none in a browser tab, which is always the
  deployment that was last pushed.
• The same footer was claiming "Blazor WebAssembly · runs 100% in your browser" inside a WPF
  window, where neither half is true; so was the .NET badge's tooltip. Both now come from the host.

The version is written down, and guarded

DesktopRelease.Version is a constant, not a lookup: GitHub's /releases/latest resolves to
whichever release is newest overall, and this repository publishes two independent tag lines on
purpose — about half the time "latest" is a NuGet release with no zip on it.

Writing it down means it can go stale, so it is not left to memory: the release workflow refuses
to build a desktop-v* tag whose version disagrees with the page. A release that forgets the edit
does not ship, and the button can never offer a version nobody published.

Merge order matters

The page offers 0.4.0, which is not published yet. The guard forces this sequence:

1. Merge this PR (the constant reaches main).
2. Cut desktop-v0.4.0 — the workflow now finds 0.4.0 on both sides and builds.

Between the two, Pages will serve a button that 404s. That window is minutes, and nobody has this
URL yet. Cutting the tag against this branch first also works, if you would rather have none at all.

Checks

371 tests, 8 new. Rendered and read at 1280 and 390 px, in both languages, before committing.

🤖 Generated with Claude Code

https://claude.ai/code/session_015PEbbiYSNPw7jE3LrPNhyF