docs: name the readers of the linux-x86_64 fallback after self-review

The fallback key is also read by the AppImage installs of v0.4.2 to
v0.4.5 (bundled until v0.7.3, published on Forgejo for v0.4.2-v0.4.3
and on the GitHub mirror for v0.4.3-v0.4.5, all reading the registry),
which look up linux-x86_64-appimage, absent, then linux-x86_64. Like a
marker-less binary, they cannot install the .deb it serves: the updater
writes its bytes over the running AppImage. State since v0.4.2, not
changed by this PR; the key stays as decided.

Also quote the error the update card really shows for a refused
package (invalid updater binary format).

Refs #320

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/architecture.md

@@ -621,7 +621,7 @@ Déclenché par les tags `v*`. Un seul job, `build-and-release`, dans un contene
 
 Fonctionnalités :
 - Signature des binaires (clés TAURI_SIGNING_PRIVATE_KEY)
-- JSON d'updater (`latest.json`) écrit par `scripts/build-latest-json.sh` à partir des assets ([#320](https://git.lacompagniemaximus.com/maximus/simpl-resultat/issues/320)). `tauri-plugin-updater` cherche `{os}-{arch}-{installer}`, puis `{os}-{arch}` : le fichier porte `linux-x86_64-deb` et `linux-x86_64-rpm` (une clé par paquet Linux), `linux-x86_64` (le `.deb`, repli d'un binaire sans type de paquet connu, condition de retrait dans `docs/qa-update-cycle.md`) et `windows-x86_64` (l'installeur NSIS). Le script échoue s'il ne trouve pas exactement un `.deb`, un `.rpm` et un `-setup.exe`, chacun avec un `.sig` non vide ; le JSON vient de `jq` seul (notes lues comme données par `--rawfile`), avec les noms de fichiers encodés par `@uri`, comme à l'envoi des assets. Testé par `scripts/build-latest-json.test.mjs` (vitest, lancé par `check-frontend`), qui l'exécute sous `bash -e -o pipefail` comme `release.yml`.
+- JSON d'updater (`latest.json`) écrit par `scripts/build-latest-json.sh` à partir des assets ([#320](https://git.lacompagniemaximus.com/maximus/simpl-resultat/issues/320)). `tauri-plugin-updater` cherche `{os}-{arch}-{installer}`, puis `{os}-{arch}` : le fichier porte `linux-x86_64-deb` et `linux-x86_64-rpm` (une clé par paquet Linux), `linux-x86_64` (le `.deb`, en repli : raison, lecteurs connus et condition de retrait dans `docs/qa-update-cycle.md`) et `windows-x86_64` (l'installeur NSIS). Le script échoue s'il ne trouve pas exactement un `.deb`, un `.rpm` et un `-setup.exe`, chacun avec un `.sig` non vide ; le JSON vient de `jq` seul (notes lues comme données par `--rawfile`), avec les noms de fichiers encodés par `@uri`, comme à l'envoi des assets. Testé par `scripts/build-latest-json.test.mjs` (vitest, lancé par `check-frontend`), qui l'exécute sous `bash -e -o pipefail` comme `release.yml`.
 - JSON publié sur `https://git.lacompagniemaximus.com/api/packages/maximus/generic/simpl-resultat/latest/latest.json` (registre de paquets, endpoint de `tauri.conf.json`). Avant le `DELETE` de l'ancienne version, une assertion `jq` (version égale au tag, exactement les quatre clés, signatures non vides, extension de chaque URL) arrête le job si le fichier ne la passe pas : le registre reste intact.
 - Release Forgejo automatique avec assets et release notes extraites du CHANGELOG.md, transmises par `GITHUB_OUTPUT` sous un délimiteur aléatoire (une ligne du CHANGELOG égale à un délimiteur fixe terminait la valeur)
 

docs/qa-update-cycle.md

@@ -74,7 +74,7 @@ Même parcours que le §2, sur la machine Fedora ou openSUSE. L'updater y lance
 - [ ] Authentifier → `readyToInstall`, puis cliquer → `installing`, l'app redémarre.
 - [ ] Vérifier la version, re-vérifier → `upToDate`.
 
-  > Un refus juste après le téléchargement (« format de mise à jour invalide ») est le défaut d'avant #320 : l'installation a reçu le `.deb`. Vérifier que le `latest.json` publié porte la clé `linux-x86_64-rpm` (`verify-release.sh`, étape 9 de `/release`).
+  > Une erreur `invalid updater binary format` sur la carte, juste après le téléchargement, est le défaut d'avant #320 : l'installation a reçu le `.deb` et l'a refusé. Vérifier que le `latest.json` publié porte la clé `linux-x86_64-rpm` (`verify-release.sh`, étape 9 de `/release`).
 
 **Pas encore déroulé** : aucune machine Fedora ou openSUSE n'était disponible quand #320 a ajouté la clé `linux-x86_64-rpm`. Le dérouler dès qu'il y en a une ; d'ici là, l'écrire « non déroulé », avec la raison, dans la trace de la release.
 
@@ -88,10 +88,17 @@ Les installations `.rpm` existantes n'ont rien à réinstaller : le binaire du `
 |---|---|---|
 | `linux-x86_64-deb` | `.deb` | les installations `.deb` |
 | `linux-x86_64-rpm` | `.rpm` | les installations `.rpm` (#320) |
-| `linux-x86_64` | `.deb` | un binaire Linux sans marqueur de type de paquet (repli) |
+| `linux-x86_64` | `.deb` | un binaire Linux sans marqueur de type de paquet, et les AppImage v0.4.2 à v0.4.5 (repli, voir ci-dessous) |
 | `windows-x86_64` | `-setup.exe` | les installations NSIS, qui cherchent d'abord `windows-x86_64-nsis` |
 
-**Repli `linux-x86_64`.** Raison : un binaire sans marqueur de type de paquet ne cherche que cette clé ; sans clé à son nom, sa vérification échoue (`TargetsNotFound`) au lieu de répondre. Condition de retrait : quand aucune version supportée n'est antérieure au marqueur. Relevé le 2026-10-10 : toutes les versions qui embarquent l'updater (v0.2.1 et suivantes) ont été empaquetées par `@tauri-apps/cli` 2.10.0, d'après le `package-lock.json` de chaque tag, comme la v0.17.1 dont le `.rpm` porte le marqueur. Un binaire sans marqueur ne saurait d'ailleurs pas installer le `.deb` : faute de type connu, l'updater le traite comme une AppImage.
+**Repli `linux-x86_64`.** Raison : un binaire sans marqueur de type de paquet ne cherche que cette clé ; sans clé à son nom, sa vérification échoue (`TargetsNotFound`) au lieu de répondre. Condition de retrait : quand aucune version supportée n'est antérieure au marqueur. Relevé le 2026-10-10 : toutes les versions qui embarquent l'updater (v0.2.1 et suivantes) ont été empaquetées par `@tauri-apps/cli` 2.10.0, d'après le `package-lock.json` de chaque tag, comme la v0.17.1 dont le `.rpm` porte le marqueur.
+
+Les lecteurs connus de cette clé ne savent pas installer le `.deb` qu'elle sert :
+
+- un binaire sans marqueur, lancé hors de son paquet ;
+- les AppImage des v0.4.2 à v0.4.5, publiées sur Forgejo pour les v0.4.2 et v0.4.3 et sur le miroir GitHub pour les v0.4.3 à v0.4.5. Leur updater lit déjà le registre, et elles cherchent `linux-x86_64-appimage`, absente, puis cette clé.
+
+Pour les deux, l'updater traite le téléchargement comme une AppImage (`install_appimage`) et écrit les octets du `.deb` à la place du fichier lancé, ce qui casse l'installation. C'est l'état depuis la v0.4.2, que #320 ne change pas.
 
 ---
 

scripts/build-latest-json.sh

@@ -29,8 +29,10 @@
 #   linux-x86_64      the .deb again: the fallback of a binary without a
 #                     bundle-type marker, which looks up this key alone.
 #                     Remove it once no supported version predates the
-#                     marker (docs/qa-update-cycle.md, "Les clés de
+#                     marker. AppImage installs (v0.4.2 to v0.4.5) read it
-#                     latest.json").
+#                     too, and neither they nor a marker-less binary can
+#                     install a .deb: see docs/qa-update-cycle.md, "Les
+#                     clés de latest.json".
 #   windows-x86_64    the NSIS installer. An NSIS install looks up
 #                     windows-x86_64-nsis first, then this key.
 #