release: git-arboretum 3.4.0 (visibilité temps réel, historisation), desktop 0.2.0 (Windows, logo), vscode 0.4.1, site 0.4.0

Tout est additif : PROTOCOL_VERSION inchangé, aucune rupture d'API.

Temps réel réellement armé
- `pinSession` n'était appelé nulle part : une session vivante épingle désormais le watcher FS de son
  worktree (`WorktreeManager.syncSessionPin` + `resolveWorktreeForCwd`), donc un worktree où un agent
  écrit se rafraîchit même si personne ne le regarde (mesuré ~350 ms).
- Les abonnements `watch` sortent de `GitPanel`, démonté dès qu'on quitte son onglet, ce qui coupait le
  seul abonnement de toute l'app : `composables/useWatchedWorktrees.ts` (monté dans App.vue) suit le
  worktree actif et les dépôts dépliés, borné à 40.
- Une coupure WS ne laisse plus l'UI sur des listes périmées : rechargement complet au retour.
- `worktree_changes` alimente `worktrees.changeVersion`, consommé par l'arbre de fichiers, le diff
  (son `:version` était câblé à 0) et l'éditeur, qui recharge un tampon propre ou lève la bannière de
  conflit avant la sauvegarde au lieu d'attendre le 409.

Corrélation session ↔ worktree par contenance (`@arboretum/shared/path-match.ts`)
- Un terminal lancé dans un sous-répertoire (« Démarrer le projet ») ou une session de groupe reliée
  par `--add-dir` apparaissent enfin sous leur worktree ; le worktree le plus spécifique gagne.
- Règle unique partagée par le daemon, le web et l'extension.

Historisation
- `commitLog` / `commitDiff` purs, `GET /repos/:id/worktrees/log` et `diff?commit=` (hash strictement
  validé, mêmes bornes que les diffs de fichiers).
- `CommitHistory.vue` sous le panneau Git : commits, marquage des non poussés, diff déplié sur place.

Visibilité
- Compteurs git complets sur chaque worktree de l'arbre et du panneau Groupes (ils n'existaient qu'en
  barre de statut, pour le seul worktree actif), avec upstream et dernier commit en infobulle ;
  `locked`, `prunable` et un dépôt invalide sont désormais visibles.
- Le panneau Groupes montre sa composition réelle (dépôts, worktrees, sessions) et teinte l'explorateur.

Polish visuel
- Les toasts d'erreur, persistants, s'empilaient derrière les modals : téléportés au-dessus.
- Sur mobile, ouvrir un terminal ou changer d'activité n'avait aucun effet visible.
- Tailles de panneaux clampées sur la fenêtre, barres d'onglets sans scrollbar parasite, états de
  chargement et d'erreur dans les trois panneaux, accessibilité des 11 modals centralisée dans
  ModalHost, splitters au clavier, numéros de diff collants, `window.confirm` remplacé.

Windows (daemon et packaging)
- `where.exe`, PowerShell comme shell de lancement, askpass `.cmd` (clone/push HTTPS par PAT),
  `taskkill /T`, `%APPDATA%`, `arboretum install` via tâche planifiée.
- Scripts de build exécutables sur un hôte Windows (`npm.cmd`, extraction sans `unzip` ni `bash`).
- Job CI `windows-latest` conditionné par ENABLE_WINDOWS_BUILD ; procédure runner dans docs/CI_RUNNERS.md.

Logo Debian : cause racine
- Une icône unique de 895×895 atterrissait dans `hicolor/895x895`, répertoire absent d'`index.theme`
  donc ignoré par la spécification freedesktop ; et `executableName` dérivait du nom scopé du paquet
  (`@arboretumdesktop`). Jeu d'icônes standard généré + `executableName: arboretum`, plus
  `deb.synopsis` (description courte vide dans apt) et `Section: devel`.
- Runtime Node embarqué élagué : 205 → 118 Mo.
- Auto-update réparé : la release flottante `desktop-latest` que les binaires interrogent n'existait pas.

Doc et vitrine
- README/README.fr : installation par plateforme, mode serveur web (nginx, LAN), dépannage, variables
  d'environnement, flags manquants.
- Doc in-app réécrite (elle renvoyait aux pages Worktrees et Sessions supprimées).
- Section « Accès distant » dans les Réglages ; le 403 BAD_ORIGIN nomme le flag à ajouter.
- Site : prérequis et registre npm privé (le `npx` affiché renvoyait un 404), téléchargements réels par
  plateforme, section « trois façons de l'utiliser », navigation complétée, 16 clés i18n mortes purgées.

Vérifications : 483 tests unitaires, 14 acceptances E2E vertes (dont p14/p15 nouvelles), captures de
rendu sans erreur console (nouveau `verify-ui.mjs`), .deb reconstruit et contrôlé (icônes aux tailles
standard, entrée .desktop valide).

docs/CI_RUNNERS.md

@@ -0,0 +1,134 @@
+# Runners Gitea Actions · ajouter Windows (et macOS)
+
+Ce document explique comment activer le build **Windows** de l'app de bureau dans la CI. Il est écrit
+pour être appliqué tel quel sur `git.lidge.fr` (Gitea 1.25).
+
+## Pourquoi un runner Windows est obligatoire
+
+Le cross-build Windows depuis Linux **ne peut pas fonctionner**, pour deux raisons vérifiées dans
+`node_modules/@homebridge/node-pty-prebuilt-multiarch` :
+
+1. `scripts/check-prebuild.js` sort en succès dès que le binaire de l'hôte existe, donc
+   `prebuild-install` n'est jamais appelé et aucun binaire `win32` n'est téléchargé (le tarball publié
+   ne contient que `prebuilds/linux-*`) ;
+2. `scripts/post-install.js` ne copie `conpty.dll` et `OpenConsole.exe` **que si la plateforme de build
+   est win32**. Sans eux, pas de ConPTY, donc **aucun terminal** dans l'app.
+
+Un build produit sous Wine serait donc installable mais inutilisable. C'est pour cela que
+`packages/desktop/README.md` ne propose plus cette voie.
+
+## État actuel
+
+| Plateforme | Runner | Build |
+|---|---|---|
+| Linux | `ubuntu-latest` (déjà en place) | automatique à chaque tag `desktop-v*` |
+| Windows | **à enregistrer** | job `windows`, activé par la variable `ENABLE_WINDOWS_BUILD` |
+| macOS | aucun | manuel (`npm run dist:mac` sur un Mac) |
+
+Le job Windows est conditionné par `if: vars.ENABLE_WINDOWS_BUILD == 'true'`. Tant que la variable
+n'existe pas, le job est **sauté** : la release Linux part normalement. Sans cette condition, un job
+`runs-on: windows-latest` sans runner disponible resterait en attente et bloquerait la release entière.
+
+## 1. Préparer la machine Windows
+
+Prérequis (Windows 10 1809+ ou Windows 11, x64) :
+
+- **Git pour Windows** (fournit aussi `bash`, utilisé par les étapes `shell: bash` du workflow) ;
+- **Node.js 22.21.1** (même version que `NODE_VERSION` dans le workflow) ;
+- rien d'autre : `node-pty` s'installe via des binaires précompilés, aucun compilateur C++ n'est requis.
+
+Vérification rapide dans PowerShell :
+
+```powershell
+node --version   # v22.21.1
+git --version
+bash --version   # fourni par Git for Windows
+```
+
+## 2. Enregistrer le runner
+
+Récupérer un jeton d'enregistrement dans Gitea : **Site Administration → Actions → Runners → Create new
+runner** (jeton d'instance), ou au niveau du dépôt : **Settings → Actions → Runners**.
+
+Puis, dans PowerShell (répertoire dédié, par exemple `C:\actions-runner`) :
+
+```powershell
+mkdir C:\actions-runner; cd C:\actions-runner
+# Binaire act_runner pour Windows (adapter la version à celle de votre Gitea)
+Invoke-WebRequest -Uri "https://gitea.com/gitea/act_runner/releases/download/v0.2.13/act_runner-0.2.13-windows-amd64.exe" -OutFile act_runner.exe
+
+.\act_runner.exe register --no-interactive `
+  --instance https://git.lidge.fr `
+  --token <JETON_DENREGISTREMENT> `
+  --name windows-builder `
+  --labels windows-latest:host
+```
+
+Le label **`windows-latest:host`** est essentiel : `:host` signifie « exécuter directement sur la
+machine », sans conteneur (il n'y a pas d'image Docker Windows utilisable ici), et `windows-latest` est
+le nom attendu par `runs-on` dans le workflow.
+
+Démarrage manuel pour un premier essai :
+
+```powershell
+.\act_runner.exe daemon
+```
+
+## 3. Exécuter le runner en service
+
+Pour qu'il survive aux redémarrages, créer une tâche planifiée « à l'ouverture de session » (même
+principe que `arboretum install` sur Windows) :
+
+```powershell
+schtasks /Create /TN "GiteaActRunner" /TR "C:\actions-runner\act_runner.exe daemon" `
+  /SC ONLOGON /RL LIMITED /F
+schtasks /Run /TN "GiteaActRunner"
+```
+
+Alternative : [NSSM](https://nssm.cc/) pour un vrai service Windows, si le runner doit tourner sans
+session ouverte. Attention : un service hors session n'a pas accès au profil utilisateur.
+
+## 4. Activer le job dans la CI
+
+Dans Gitea, sur le dépôt `johanleroy/arboretum` : **Settings → Actions → Variables → Add Variable**
+
+| Nom | Valeur |
+|---|---|
+| `ENABLE_WINDOWS_BUILD` | `true` |
+
+## 5. Vérifier sans créer de tag
+
+Le workflow accepte `workflow_dispatch` : **Actions → Desktop Release → Run workflow**. Dans ce mode, le
+garde-fou « tag == version » est ignoré et rien n'est attaché à une release ; les installeurs sont
+récupérables dans les artefacts du run (`desktop-windows`).
+
+Contrôles à faire sur l'installeur produit :
+
+1. l'installeur NSIS s'exécute et propose le répertoire d'installation ;
+2. l'app démarre et affiche l'IDE **sans écran de connexion** (le token passe par le descripteur 3 ;
+   c'est le point le plus susceptible de différer sur Windows, cf. `packages/desktop/src/main/daemon.ts`) ;
+3. un terminal s'ouvre et répond (ConPTY présent) ;
+4. le CLI `claude` est trouvé (sinon renseigner son chemin dans Réglages → Claude CLI) ;
+5. « Démarrer le projet » lance bien les commandes sous PowerShell.
+
+## 6. Signature de code
+
+Aucun binaire n'est signé. SmartScreen affichera « éditeur inconnu » au premier lancement : choisir
+« Informations complémentaires » puis « Exécuter quand même ». Pour signer plus tard, ajouter les
+secrets `CSC_LINK` (certificat .pfx encodé en base64) et `CSC_KEY_PASSWORD` au dépôt : electron-builder
+les utilise automatiquement, sans changement de workflow.
+
+## Repli si aucun runner n'est possible
+
+Sur une machine Windows, avec le dépôt cloné :
+
+```powershell
+npm ci
+cd packages\desktop
+npm ci
+npm run dist:win
+```
+
+Puis attacher `packages\desktop\release\*.exe`, `latest.yml` et les `.blockmap` à la release
+`desktop-vX.Y.Z` depuis l'interface Gitea. Le canal d'auto-update (`desktop-latest`) doit recevoir les
+mêmes fichiers, sinon les utilisateurs Windows ne verront pas la mise à jour.