fix(mindmap): autonomous FreeMind SVG export — desktop attach + focus + tabs reset

[jsboige]

Summary

Six fixes so the FreeMind GUI automation in FallacyMindMapDocumentConfig survives unattended runs and stops silently exporting to the wrong file on large mindmaps. Validated tonight on a Windows 11 RDP session: 17/20 SVGs regenerated autonomously.

Changes

#	Fix	Why
1	TryAttachToInteractiveDesktop (P/Invoke OpenInputDesktop + SetThreadDesktop)	Process spawned from non-interactive context sees a NULL foreground → keystrokes drop. Switching the worker thread to WinSta0\Default lets GetForegroundWindow actually see FreeMind. Idempotent.
2	ForceForeground(hWnd) — AttachThreadInput + verify loop (up to 5 attempts)	Plain SetForegroundWindow is silently refused by Windows when the caller isn't already foreground. We attach our input queue to the current foreground thread for the call, BringWindowToTop, then verify GetForegroundWindow == hWnd before continuing. Re-asserted right before typing in case focus drifted.
3	SendKeysSafe(keys) — wraps SendKeys.SendWait and swallows the spurious Win32Exception (NativeErrorCode 0, "L'opération a réussi.")	Without this guard, the very first keystroke aborts the whole export. Same swallow pattern as the sibling Mindmapper/xslt/Export-FreeMindSvg.ps1.
4	ClearFreeMindAutoOpenedTabs(freemindUserDir) — empties lastOpened= and mindmap_last_state_map_storage= in ~/.freemind/auto.properties before each launch	Without this, FreeMind silently restores 5 stale tabs from previous runs; our keystrokes target whichever tab gets focus first, and SVG export lands on the wrong .svg (or none).
5	Broader KillAllFreeMind — kill ALL javaw, no MainWindowTitle.Contains("FreeMind") filter	A FreeMind still loading a large .mm has an empty/unstable title; the previous filter let it survive between iterations and steal focus from the next run. Also called on window-not-found timeout.
6	Polling timeout 30 s → 90 s	Cards-per-fallacy variants (~1 MB .mm) take 30-60 s to load on FreeMind 1.0.1. 30 s was timing out, leaving orphan javaw.

All wrapped with a try/finally that releases the input desktop handle.

Validation

• 2026-05-16 RDP session: 17/20 SVGs regenerated autonomously, all Virtues + Fallacies content/links exported successfully once the user was actively in session.
• The residual issue with Argumentum_Virtues_*.content.svg showing viewBox=" NaN NaN" is a separate post-processing regression — tracked in fix(mindmap-svg): Virtues .content.svg post-processing produces broken viewBox=" NaN NaN" — regression #274. DO NOT copy fresh Virtues SVGs back to Cards/Fallacies/Mindmaps/ until fix(mindmap-svg): Virtues .content.svg post-processing produces broken viewBox=" NaN NaN" — regression #274 is fixed.
• HTML wrapper rendering bugs found during validation tracked in fix(mindmaps): _ext.html wrappers render SVG at 300x150 default — missing #svgObject sizing #271, fix(mindmaps): Argumentation_Virtues_<lang>.html (non-ext) ships inlined SVG without viewBox — renders blank #272, fix(mindmaps): _ext.html wrappers hardcode FR placeholder card in all languages (i18n regression) #273.

Test plan

• dotnet build clean (0 errors, 15 warnings, all pre-existing)
• Re-run on a clean RDP session and confirm SVG export rate is back to 100% for the supported mindmaps
• Re-run from a Service-context / non-interactive process to confirm desktop attach actually unblocks foreground (was the original failure mode)

Limitations

• This fixes the autonomy of the export given a user is in the RDP session. Running from a true Session 0 service still depends on OpenInputDesktop succeeding — we log the Win32 error if it doesn't and fall through to legacy behaviour rather than crashing.
• The viewBox=" NaN NaN" post-processing bug (fix(mindmap-svg): Virtues .content.svg post-processing produces broken viewBox=" NaN NaN" — regression #274) is upstream of this PR and unaffected.

🤖 Generated with Claude Code