fix(startup): pin the WebView2 profile, and retry without the GPU after a hang

His log reaches 'entering wails.Run' and stops: WebView2 is installed
(120.0.2210.91) and never hands control back. A hang, not a failure —
there is no error to report, so the two remaining causes have to be
addressed rather than diagnosed.

The profile folder is now named explicitly, on the LOCAL disk. Wails
defaults it into the ROAMING profile, which on a managed account can be
redirected to a share; a WebView2 profile on a share that is slow or gone
does not fail, it hangs. Naming it also gives someone a folder they can
be told to delete, which is the fix when the profile itself is corrupt.

And a marker is written before the window is attempted, removed when it
paints. Finding it at the next launch means the last one never got there,
so that launch runs with GPU acceleration off: a WebView2 that cannot get
on with the graphics driver hangs exactly like one that cannot start, and
this is the single lever that separates them — at no cost on machines
where it was never the problem.

changelog.json

@@ -17,7 +17,8 @@
       "The satellite dropdown now follows the list as it is edited: the field read it once when the panel first appeared, so a list saved afterwards only showed up after a restart.",
       "Preferences no longer redraw with the main window. Being a child of the main view, the whole panel was rebuilt on every cluster spot and every CAT update — several times a second on a busy evening — which looked like a page refreshing constantly and made buttons miss their clicks, the element under the pointer being replaced between the press and the release.",
       "Dropdown lists open over whatever is beneath them instead of being cut off by it. The satellite list showed one entry of eight, clipped by the panel it sat in.",
-      "A launch that fails before the window exists now says why. OpsLog keeps its log in the data folder beside the program, so anything that went wrong BEFORE that folder existed left nothing to read anywhere — the process appeared and vanished in silence. Startup milestones are written to %LOCALAPPDATA%OpsLogstartup.log, and the three silent exits (already running, the data folder cannot be written — Program Files refuses it — and the window itself failing to open, usually a missing WebView2) now show a message saying which one it was. The log also names the installed WebView2 runtime — the one dependency OpsLog cannot carry inside itself, and whose absence is otherwise invisible — and marks each milestone up to the window painting, so a launch that produces nothing can be placed exactly."
+      "A launch that fails before the window exists now says why. OpsLog keeps its log in the data folder beside the program, so anything that went wrong BEFORE that folder existed left nothing to read anywhere — the process appeared and vanished in silence. Startup milestones are written to %LOCALAPPDATA%OpsLogstartup.log, and the three silent exits (already running, the data folder cannot be written — Program Files refuses it — and the window itself failing to open, usually a missing WebView2) now show a message saying which one it was. The log also names the installed WebView2 runtime — the one dependency OpsLog cannot carry inside itself, and whose absence is otherwise invisible — and marks each milestone up to the window painting, so a launch that produces nothing can be placed exactly.",
+      "WebView2 is given an explicit profile folder on the local disk (LOCALAPPDATAOpsLogWebView2) instead of the roaming default, which on a redirected or managed account can hang rather than fail. And when a launch never opens its window, the next one retries with GPU acceleration off and says so — a WebView2 that cannot get on with the graphics driver hangs exactly like one that cannot start at all, and that is the one lever telling them apart."
     ],
     "fr": [
       "Console Elecraft : les mesures d'émission sont lues dès que la RADIO se déclare en émission, et plus seulement quand OpsLog l'a mise en émission. Passer en émission par le PTT de façade, une pédale ou le bouton du micro laissait le panneau croire à une réception — et comme les barres de puissance et de ROS ne sont lues qu'en émission, elles ne l'étaient jamais pour qui manipule à la main.",
@@ -34,7 +35,8 @@
       "La liste déroulante des satellites suit maintenant la liste au fil des modifications : le champ la lisait une seule fois à l'apparition du panneau, si bien qu'une liste enregistrée ensuite n'apparaissait qu'après un redémarrage.",
       "Les préférences ne se redessinent plus au rythme de la fenêtre principale. Étant un enfant de la vue principale, tout le panneau était reconstruit à chaque spot du cluster et à chaque mise à jour CAT — plusieurs fois par seconde un soir chargé — ce qui donnait l'impression d'une page qui se rafraîchit sans arrêt et faisait rater les clics, l'élément sous le pointeur étant remplacé entre l'appui et le relâchement.",
       "Les listes déroulantes s'ouvrent par-dessus ce qui les entoure au lieu d'être coupées par lui. Celle des satellites n'affichait qu'une entrée sur huit, tronquée par le panneau qui la contenait.",
-      "Un lancement qui échoue avant l'apparition de la fenêtre dit maintenant pourquoi. OpsLog tient son journal dans le dossier data, à côté du programme : tout ce qui échouait AVANT la création de ce dossier ne laissait donc aucune trace nulle part — le processus apparaissait et disparaissait en silence. Les étapes du démarrage sont écrites dans %LOCALAPPDATA%OpsLogstartup.log, et les trois sorties silencieuses (déjà lancé, dossier data impossible à écrire — Program Files le refuse — et fenêtre qui ne s'ouvre pas, généralement un WebView2 manquant) affichent désormais un message disant laquelle c'était. Le journal indique aussi la version du runtime WebView2 installé — la seule dépendance qu'OpsLog ne peut pas embarquer, et dont l'absence est autrement invisible — et marque chaque étape jusqu'à l'affichage de la fenêtre, si bien qu'un lancement sans résultat peut être situé précisément."
+      "Un lancement qui échoue avant l'apparition de la fenêtre dit maintenant pourquoi. OpsLog tient son journal dans le dossier data, à côté du programme : tout ce qui échouait AVANT la création de ce dossier ne laissait donc aucune trace nulle part — le processus apparaissait et disparaissait en silence. Les étapes du démarrage sont écrites dans %LOCALAPPDATA%OpsLogstartup.log, et les trois sorties silencieuses (déjà lancé, dossier data impossible à écrire — Program Files le refuse — et fenêtre qui ne s'ouvre pas, généralement un WebView2 manquant) affichent désormais un message disant laquelle c'était. Le journal indique aussi la version du runtime WebView2 installé — la seule dépendance qu'OpsLog ne peut pas embarquer, et dont l'absence est autrement invisible — et marque chaque étape jusqu'à l'affichage de la fenêtre, si bien qu'un lancement sans résultat peut être situé précisément.",
+      "WebView2 reçoit un dossier de profil explicite sur le disque local (LOCALAPPDATAOpsLogWebView2) au lieu du dossier itinérant par défaut, qui sur un compte redirigé ou administré peut bloquer au lieu d'échouer. Et lorsqu'un lancement n'ouvre jamais sa fenêtre, le suivant réessaie sans accélération GPU et le dit — un WebView2 qui ne s'entend pas avec le pilote graphique se bloque exactement comme un WebView2 qui ne démarre pas, et c'est le seul levier qui les distingue."
     ]
   },
   {