test(desktop): failure parity for the write commands, and the three defects it found

[devlint]

Seconde moitié du lot v3.11.0 « audit de dérive des routes dev-server », après #203 qui en a livré le registre. Avec elle, le lot est complet.

Pourquoi

pnpm dev:web lance dev-server.mjs, pas le backend Rust. Les deux s'accordent sur les chemins heureux — ce sont les chemins d'échec qui avaient déjà divergé sans que rien ne le voie : read_file refusait le non-UTF-8 côté Rust et substituait U+FFFD côté Node.

Ce que fait cette PR

Un bras de probe générique. Seules 5 des 35 commandes d'écriture étaient joignables depuis le harnais ; les 30 autres auraient demandé chacune un wrapper *_parity et un bras. Un unique command-parity, prenant { command, args } en JSON sur stdin et dispatchant par match, remplace trente paires par trente branches courtes.

31 tests de parité sur les chemins d'échec, couvrant 27 commandes d'écriture. Chacun asserte que les deux backends refusent et laissent le même dépôt derrière : s'accorder sur « non » en laissant des arbres de travail différents n'est pas de la parité, puisque c'est l'état que l'utilisateur manipule ensuite. La suite passe de 81 à 112 tests sans ralentir (~21 s).

Trois défauts trouvés, tous corrigés

1. Une mise à jour de sous-module qui échoue était rapportée comme réussie. /api/git-submodule-update-one lançait git submodule update et jetait le code de sortie, répondant {} quoi qu'il arrive, pendant que le Rust propageait l'erreur.
2. /api/git-commit-template-path n'existait pas. backend.ts l'appelait, donc la recherche de template de commit retournait silencieusement null en mode web.
3. /api/git-config-identity n'existait pas non plus. Même cause, conséquence différente : le wrapper levait une exception.

Les deux routes écrites reprennent les arbitrages du Rust plutôt que de les approcher : un commit.template non configuré n'est pas une erreur, un user.name ou user.email vide en est une, et l'expansion du ~ initial est reproduite. Quatre tests de parité les épinglent.

Hors couverture, et pourquoi

• git_fetch prend un tauri::ipc::Channel<CloneProgress> : aucun processus sans runtime Tauri ne peut l'appeler. La couvrir demande de scinder le travail git du rapport de progression — un refactor, pas un test.
• workspace_fetch_all / workspace_pull_all renvoient un Vec<WorkspaceRepoStatus> sans Result : pas de refus à comparer, la parité y aurait une autre forme.
• snapshot_create répond Ok(None) au lieu d'échouer, même sur un répertoire qui n'est pas un dépôt : pas de refus atteignable. Le cas a été retiré avec sa raison plutôt que remplacé par une fixture qui aurait testé la fixture.
• 9 trous du registre restent ouverts (git_autocomplete, git_conflict_check, set_git_config, les deux scratch_worktree_*, les quatre mcp_*) : pas de route, aucun obstacle à en avoir une. Contrairement aux deux 404 corrigés ici, ce ne sont pas des défauts actifs — ces commandes sont simplement indisponibles sous dev:web, ce qui se voit dès qu'on les utilise.

Un garde-fou ajouté en cours de route

Le dispatcher répond command-parity does not know 'X' pour un bras manquant, ce qui ressemble exactement à un refus. Avec un binaire de probe périmé, tous les tests de ce fichier passent alors au vert pour la mauvaise raison — c'est arrivé une fois pendant l'implémentation et a produit deux fausses « divergences ». Le helper lève désormais une erreur explicite qui dit de reconstruire.

Le fichier documente aussi deux pièges de fixture qui ont chacun coûté un aller-retour : git stash sur un arbre propre sort 0 (« No local changes to save »), donc ce n'est pas un refus ; et « dépôt sans identité » ne s'obtient pas en s'abstenant de configurer, puisque les deux backends héritent de la config git globale de la machine.

Tests

Parité 112 / 25 fichiers, desktop 1412 / 164, Rust 404, cargo fmt --check propre, vue-tsc --noEmit propre, pnpm build OK.