v2.0.0 — the rewrite, no longer an alpha

First non-alpha release of the rewrite. The 0.9.x line lives on main; nothing there was deleted.

All five packages below were built in one run from the build inputs of commit 59cfee6, and
npm run verify:release passes all eight checks against them — including "no artefact predates
the last build-input commit" and "build claims name their commit", so the version number on these
files stands for exactly one payload.

cd ~/Downloads
B=https://github.com/chicohaager/zima-linux-client/releases/download/v2.0.0

wget $B/install.sh $B/SHA256SUMS-2.0.0.txt          # always these two

wget $B/zima-linux-client_2.0.0_amd64.deb           # Debian, Ubuntu, Zorin, Mint, Pop!_OS, PikaOS
wget $B/zima-linux-client-2.0.0.x86_64.rpm          # Fedora, openSUSE, RHEL derivatives
wget $B/zima-linux-client-2.0.0.pacman              # Arch, Manjaro

chmod +x install.sh && sudo ./install.sh

First non-alpha release of the v2 line. Built from 59cfee6; this tag sits on
8ab8ed8, which only corrects the build claim in the status document.

What changed since alpha.4 — both from forum reports:

• An app's web UI window had no failure path at all. The result of loadURL
  was discarded and nothing listened, so an unreachable app left a white
  window with no message: measured at 21 s to the first event and still
  empty after 90 s. It now shows a connecting page immediately and, on
  failure, names the app, the address and Chromium's own reason, in the
  user's language.
• The "you need the Photos module" notice appeared twice for people who do
  not want that module, and is gone from both places. The Photos tab
  browses folders instead; photo backup works without the module.
• The Photos tab's empty state was unreachable in both modes: one of its two
  queries is always disabled, and a disabled react-query reports pending for
  ever, so an empty folder said "Loading..." indefinitely.

One thing to know about the AppImage checksum

GitHub replaces the space in the AppImage's filename with a dot when it stores an asset, so what
you download is ZimaOS.Client-2.0.0.AppImage while SHA256SUMS-2.0.0.txt names
ZimaOS Client-2.0.0.AppImage. sha256sum -c therefore reports "No such file or directory"
for that one line — which looks like a tampered download and is not. The other four packages
verify normally.

Check the AppImage like this instead:

sha256sum ZimaOS.Client-2.0.0.AppImage
grep AppImage SHA256SUMS-2.0.0.txt      # the two hashes must match

This has been true since the first alpha and was only measured now. It will be fixed at the
source in the next build by giving the artefact a name without a space.

Measured before publishing:

release gate      8 of 8, clean
distro matrix     9 of 9 against exactly these files — Ubuntu 22.04,
                  24.04, 26.04 LTS; Debian 12, 13; Fedora 41, 44; Arch;
                  openSUSE Tumbleweed. Sandbox on, ordinary user, real
                  install path, 51 CSS rules applied, 399 characters of
                  visible text, no raw translation keys.
npm run verify    exit 0, 315 tests in 37 files
playwright        5 of 5

Not covered: arm64 (a settled decision, not published), Debian SID
(installation measured, no start), and real-hardware coverage beyond Ubuntu
24.04, Zorin OS 18 and a third-party Fedora KDE report. One open bug: an
HTTP 400 in the Photos tab reported on Fedora, cause still unmeasured.

On the version number: 1.0 was asked for and rejected after measuring — dpkg
orders 1.0.0 BELOW 2.0.0~alpha.4, so testers on alpha.4 would never have been
offered the update.