Let a failed update check say so, instead of reporting good news

The phone reported every build as current because the release repository is
private. Gitea answers 404 rather than 403 for a repo you cannot see, the client
reads that address anonymously, and AndroidUpdateChannel caught the failure and
returned null — which IUpdateChannel documented as meaning "this build is the
latest". The check had never once succeeded on any phone and nothing anywhere
said so.

Two faults, and the second is why the first lasted.

The seam said null was the honest answer for an unreachable channel, on the
reasoning that the caller does the same thing either way. That is true of the
six-hourly pass and false of CHECK NOW. UpdateViewModel already draws the line
correctly — silent on the timer, the exception's message on the button — and it
could only ever draw the first half, because nothing was ever thrown at it. The
desktop's channel does not catch, so the interface described neither
implementation.

So CheckAsync throws now, and null means one thing. A release that is reachable
but missing its manifest or the APK it names throws too: "you are up to date"
about a half-published feed is the same lie in a smaller costume, and the
self-healing that argument protected is untouched, since the timer still swallows
everything.

The precondition is written down where somebody would look, rather than left as a
sentence about where a token could live. ADR 0013 §4 already said a private
release repository was incompatible with this design; nobody checked which side
of it this repository was on. It is one curl, and manual-checks phase 16 now
opens with it — pointedly not against /api/v1/version, which answers 200 from a
forge that is up whatever is readable on it, and which is what made this look
like nothing was wrong.

Phone check 17.4 was the one that passed all along. It now presses CHECK NOW with
the network off as well as on, because two different answers are the whole of
what makes the first one worth reading.

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

@@ -110,6 +110,23 @@ private release repository is incompatible with this design and that is worth kn
 discovering, because the token would have to be readable before the vault is unlocked, and this file is the
 one place that can be read then — which is the one place a token may not go.
 
+◆ **It was discovered.** The paragraph above was written and the repository was private anyway, so every
+check on every client asked an address that answers `404` — Gitea does not distinguish "not there" from
+"not yours" — and both heads reported the running build as current. It had never once worked, on either
+platform, and nothing anywhere said so. Two things came out of that and both are now written down rather
+than assumed:
+
+- **The feed repository must be readable with no credentials, and that is a deployment precondition** rather
+  than a property of the code. It is checkable in one line, which is the only reason it is worth stating:
+  `curl -so /dev/null -w '%{http_code}' https://git.dodotech.cloud/api/v1/repos/DodoTech/DodoSSH` answers
+  `200` when the design holds and `404` when it does not. `/api/v1/version` answering `200` proves only that
+  the forge is reachable, which is what made this look like nothing was wrong.
+- **An unreachable channel must be distinguishable from a current build.** `IUpdateChannel.CheckAsync` used
+  to document null as the honest answer for both, on the reasoning that the caller does the same thing
+  either way. That is true of the six-hourly pass and false of CHECK NOW, and it is what turned a total
+  outage into a reassuring sentence. It throws now, and `UpdateViewModel` keeps the distinction it always
+  had: silent on the timer, the exception's own message on the button.
+
 ### 5. `MinClientVersion` stays unread, and if it is ever read it may not fetch
 
 `MetaResponse.MinClientVersion` has existed since M1, is served, is fetched on every sign-in, and is read