Name the organisation the repository actually lives in

It moved to DodoTech-Public, and every address in the product still said
DodoTech. That looked like it worked, which is the part worth writing down:
Gitea leaves a 301 at the old path and HttpClient follows a redirect on a GET, so
both update channels would have kept polling through it.

What a 301 does not survive is a POST. `vpk upload gitea` publishes the desktop
release by POSTing to that URL, so the stale address would have failed at the one
step the whole feature depends on — and a redirect is a thing an operator can
delete, which turns "works today" into the same silent outage this session has
already spent two commits on.

So both channel constants, both release scripts, the workflow's REPO, the image's
source label and the curl in phase 16 all name the live path. The local remote
too, which had been printing a redirect warning on every push.

Measured after the move: the org, the repo and the nightly release all answer 200
anonymously, and that release now carries both assets — the manifest and a 54 MB
APK. The upload going through also answers the open question about the reverse
proxy's body-size limit, which nothing local could test.

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

@@ -118,7 +118,7 @@ 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
+  `curl -so /dev/null -w '%{http_code}' https://git.dodotech.cloud/api/v1/repos/DodoTech-Public/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