fix: la section Aide est positionnée comme Settings (v7.69.3)

La section Aide et la section Settings partagent le même gabarit
(`.settings-overlay` / `.settings-panel`) et la même feuille de style
(`static/css/settings.css`), mais affichaient deux rendus différents.

Cause : `help.html` neutralisait son overlay via un style INLINE sur la balise
— `position:static`, `background:none`, `backdrop-filter:none`, `padding:0` —
et imposait par-dessus un panneau `width:100%;max-width:1050px;
height:calc(100vh - 120px);margin:0 auto`. Settings, lui, laissait
`settings.css` faire son travail : overlay `fixed;inset:0` avec fond flouté,
panneau `85vh` centré par `margin:auto`.

Résultat perçu : Aide s'affichait comme un bloc posé dans la page, Settings
comme une modale centrée floutant l'arrière-plan — malgré un code quasi
identique.

Correctif : les surcharges inline sont retirées de `help.html`. La géométrie
vient désormais entièrement de `settings.css`, commun aux deux pages. Aucune
valeur n'est dupliquée ; les deux balises sont strictement identiques.

Vérifié en e2e en comparant les géométries CALCULÉES des deux pages (pas des
valeurs de code) : overlay `fixed` avec fond opère des deux côtés, panneau
1050x765 centré à top:68px, bouton close à 13/13px du coin du panneau — les
deux jeux de mesures sont identiques.

Tests : `tests/test_v7693_help_positioning.py` (5) verrouille l'absence de
surcharges inline et l'identité de balise avec Settings ;
`e2e/v7693_help_positioning.spec.js` compare les géométries calculées.

NON INCLUS — double-clic sur le bouton close de Settings :
le bug a été REPRODUIT en e2e et sa cause racine identifiée, mais le correctif
n'est volontairement PAS dans ce commit. Voir ROADMAP.md § v7.69.3 pour le
relevé complet et la prochaine étape.

pytest 1421 passed / 0 failed · ruff OK · e2e 15/15 verts sur l'instance déployée

ROADMAP.md

@@ -1581,6 +1581,51 @@ le marqueur de troncature du message d'erreur, **pas** un bug produit — une he
 passée à chercher une fuite inexistante. Vérifier `JSON.stringify()` de la valeur
 réelle avant de croire un affichage tronqué.
 
+---
+
+### v7.69.3 — Aide alignée sur Settings ✅ · double-clic close ⏳ ouvert (2026-10-08)
+
+**Livré** : la section Aide partage maintenant le positionnement exact de la
+section Settings. `help.html` neutralisait son overlay en style inline
+(`position:static`, fond transparent, sans blur, sans padding) et forçait un
+panneau `1050px / 100vh-120px` — les deux pages pourtant identiques au CSS
+près produisaient deux rendus. Surcharges retirées ; e2e compare les
+géométries calculées : **identiques des deux côtés** (overlay `fixed` avec
+fond, panneau 1050×765 centré, close à 13/13 px du coin).
+
+**Non livré — double-clic sur le bouton close de Settings.** Cause racine
+trouvée, correctif NON appliqué (non vérifié sur le parcours réel).
+
+Relevé d'investigation, à ne pas refaire :
+
+- **Cause racine** : Alpine ne LIE PAS le composant `x-data="settingsInit()"`
+  dans certains contextes. Mesure sur un onglet où Settings a été ouvert via
+  `target="_blank"` :
+  `window.Alpine` existe, mais `button.settings-close._x_dataStack` est absent
+  → `@click="closeSettings()"` est **inerte**. Le premier clic ne fait rien du
+  tout — ce qui correspond au symptôme rapporté. Ce n'est PAS la logique de
+  navigation qui est en cause.
+- **Le bug se reproduit en e2e** : ouvrir `/settings` depuis un onglet distinct
+  (`target="_blank"` avec `rel="opener"`), cliquer `button.settings-close` →
+  l'URL reste `/settings`. Un test l'a confirmé (`APRES 1 clic= /settings`),
+  sans `pageerror` ni message console : le handler ne s'exécute simplement pas.
+- **Ce qu'il ne faut PAS faire** : réécrire `closeSettings()`. L'ancienne
+  implémentation (`window.opener` → `window.close()`, sinon `history.back()` +
+  `reload()` après 100 ms) a été modifiée puis **annulée** : elle n'avait aucun
+  effet sur le cas reproduit. Le `return` inconditionnel de la branche
+  `window.opener` reste un défaut réel (`window.close()` échoue en silence si
+  l'onglet n'a pas été ouvert par du script), mais il n'est pas la cause
+  rapportée.
+- **Thèse de la course réfutée** : un retour plus lent que 100 ms ne provoque
+  pas le symptôme (testé avec 400 ms de latence, un seul clic suffit).
+- Parcours de référence qui, lui, **fonctionne en un clic** : `/local-workspace`
+  → menu avatar → Settings (chargement de page complet).
+
+**Prochaine étape concrète** : déterminer pourquoi `settingsInit()` échoue à
+s'initialiser — `settings.js` est-il chargé dans ce contexte ? Vérifier
+`x-data` au chargement et la présence d'une erreur CSP/nonce sur le script.
+
+
 ---
 
 ## ✅ Fonctionnalités livrées hors roadmap (bonus détectés dans le code)