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).

packages/server/src/core/claude-launcher.ts

@@ -1,5 +1,5 @@
 import { execFileSync } from 'node:child_process';
-import { accessSync, constants } from 'node:fs';
+import { accessSync, constants, existsSync } from 'node:fs';
 
 export interface SpawnSpec {
   file: string;
@@ -13,7 +13,7 @@ export interface SpawnOptions {
   resume?: { claudeSessionId: string; fork?: boolean };
   /** répertoires supplémentaires à relier dans une seule session (P6) : `--add-dir <path>` répété. */
   addDirs?: string[];
-  /** chemin explicite du binaire `claude` (réglage UI) ; sinon résolution via PATH (`which`). */
+  /** chemin explicite du binaire `claude` (réglage UI) ; sinon résolution via le PATH. */
   claudeBinPath?: string | null;
   /**
    * Lancement de projet (« Démarrer le projet ») : au lieu de `bash --norc`, lance le shell de
@@ -22,6 +22,8 @@ export interface SpawnOptions {
    * (PATH minimal, cf. resolveClaudeBin) : sinon `npm`/`docker` seraient introuvables. Ignoré pour claude.
    */
   login?: boolean;
+  /** plateforme cible (injectable pour les tests) ; défaut `process.platform`. */
+  platform?: NodeJS.Platform;
 }
 
 /** Diagnostic de résolution du binaire `claude` (exposé en lecture dans Réglages). */
@@ -36,16 +38,32 @@ export interface ClaudeBinDiagnostic {
 
 let cachedClaudeBin: string | null = null;
 
+/**
+ * Commande de recherche dans le PATH selon la plateforme : `which` n'existe PAS sur Windows, c'est
+ * `where.exe` (qui peut renvoyer plusieurs lignes, la première étant la retenue).
+ */
+export function whichCommand(platform: NodeJS.Platform = process.platform): { file: string; args: string[] } {
+  return platform === 'win32' ? { file: 'where.exe', args: ['claude'] } : { file: 'which', args: ['claude'] };
+}
+
 /** Recherche `claude` dans le PATH (sans throw). null si absent. */
-function findClaudeOnPath(): string | null {
+function findClaudeOnPath(platform: NodeJS.Platform = process.platform): string | null {
+  const { file, args } = whichCommand(platform);
   try {
-    return execFileSync('which', ['claude'], { encoding: 'utf8' }).trim() || null;
+    const out = execFileSync(file, args, { encoding: 'utf8' });
+    // `where.exe` liste toutes les correspondances : on garde la première.
+    return out.split(/\r?\n/).map((l) => l.trim()).find((l) => l.length > 0) ?? null;
   } catch {
     return null;
   }
 }
 
-function isExecutable(path: string): boolean {
+/**
+ * « Est-ce lançable ? ». Sur Windows, le bit d'exécution POSIX n'a aucun sens (NTFS n'en a pas) et
+ * `accessSync(X_OK)` y répond au hasard : on se contente donc de l'existence du fichier.
+ */
+function isExecutable(path: string, platform: NodeJS.Platform = process.platform): boolean {
+  if (platform === 'win32') return existsSync(path);
   try {
     accessSync(path, constants.X_OK);
     return true;
@@ -57,9 +75,9 @@ function isExecutable(path: string): boolean {
 /**
  * Résout le binaire `claude`. Si `configuredPath` est fourni (réglage UI), il est utilisé tel quel
  * (validé exécutable, message clair sinon) et JAMAIS mis en cache (modifiable à chaud). Sinon :
- * `which claude`, mis en cache. Un service systemd/launchd démarre avec un PATH minimal sans
- * ~/.local/bin → `which claude` y échoue ; d'où le réglage de chemin explicite (et le PATH figé par
- * `arboretum install`).
+ * recherche dans le PATH (`which` / `where.exe`), mise en cache. Un service systemd/launchd démarre
+ * avec un PATH minimal sans ~/.local/bin → la recherche y échoue ; d'où le réglage de chemin explicite
+ * (et le PATH figé par `arboretum install`).
  */
 export function resolveClaudeBin(configuredPath?: string | null): string {
   if (configuredPath) {
@@ -92,32 +110,48 @@ export function diagnoseClaudeBin(configuredPath?: string | null): ClaudeBinDiag
 const KNOWN_LOGIN_SHELLS = new Set(['bash', 'zsh', 'fish']);
 
 /**
- * Shell de login pour « Démarrer le projet » : `$SHELL` s'il est un shell interactif connu
- * (bash/zsh/fish), sinon fallback `bash`. Évite qu'un `$SHELL` exotique (dash…) sorte aussitôt
- * avec `-l -i` et laisse un terminal vide.
+ * Shell interactif pour « Démarrer le projet ».
+ *
+ * POSIX : `$SHELL -l -i` s'il fait partie des shells connus supportant ces options (bash/zsh/fish),
+ * sinon `bash` (un `$SHELL=dash` sortirait aussitôt avec `-l -i`, laissant un terminal vide).
+ *
+ * Windows : PowerShell, en restant attaché après la commande auto-tapée (`-NoExit`), avec repli sur
+ * `cmd.exe /K`. `%COMSPEC%` n'est PAS utilisé comme shell de lancement : il pointe cmd.exe, qui ne
+ * charge aucun profil utilisateur. La commande est ensuite auto-tapée par le PtyManager, exactement
+ * comme sous POSIX · le mécanisme est indépendant du shell.
  */
-function loginShell(): string {
-  const shell = process.env.SHELL;
-  if (shell && KNOWN_LOGIN_SHELLS.has(shell.split('/').pop() ?? '')) return shell;
-  return 'bash';
+export function resolveInteractiveShell(
+  platform: NodeJS.Platform = process.platform,
+  env: NodeJS.ProcessEnv = process.env,
+): { file: string; args: string[] } {
+  if (platform === 'win32') {
+    const pwsh = env.ARBORETUM_SHELL ?? 'powershell.exe';
+    return { file: pwsh, args: ['-NoLogo', '-NoExit'] };
+  }
+  const shell = env.SHELL;
+  const file = shell && KNOWN_LOGIN_SHELLS.has(shell.split('/').pop() ?? '') ? shell : 'bash';
+  return { file, args: ['-l', '-i'] };
+}
+
+/** Shell non interactif « neutre » (terminal simple, hors lancement de projet). */
+export function resolvePlainShell(platform: NodeJS.Platform = process.platform): { file: string; args: string[] } {
+  if (platform === 'win32') return { file: 'powershell.exe', args: ['-NoLogo', '-NoExit'] };
+  return { file: 'bash', args: ['--norc'] };
 }
 
 /** Module volontairement abstrait : le plan B « BYO API key / Agent SDK » se brancherait ici. */
 export function buildSpawnSpec(opts: SpawnOptions): SpawnSpec {
+  const platform = opts.platform ?? process.platform;
   const env: NodeJS.ProcessEnv = {
     ...process.env,
     TERM: 'xterm-256color',
     COLORTERM: 'truecolor',
   };
   if (opts.command === 'bash') {
-    // Lancement de projet : shell de login interactif de l'utilisateur (charge PATH/nvm/asdf).
-    // `-l` (login) exécute les profils, `-i` (interactif) reste attaché après la commande auto-tapée.
-    // On n'utilise `$SHELL` que s'il fait partie des shells interactifs connus supportant `-l -i`
-    // (bash/zsh/fish) ; sinon fallback bash (ex. `$SHELL=dash` sortirait avec `-l -i`).
-    if (opts.login) {
-      return { file: loginShell(), args: ['-l', '-i'], env };
-    }
-    return { file: 'bash', args: ['--norc'], env };
+    // `'bash'` désigne « le shell de la machine », pas littéralement bash : le contrat d'API reste
+    // stable (claude|bash) et c'est ici qu'on choisit le shell réel par plateforme.
+    const { file, args } = opts.login ? resolveInteractiveShell(platform) : resolvePlainShell(platform);
+    return { file, args, env };
   }
   const args: string[] = [];
   if (opts.resume) {