Add live tool output console for the Linux GUI

[gmipf]

What

On Linux the dumping tools (redumper, DiscImageCreator, Aaru) run without a console window of their own, so their live progress output was not visible anywhere in the GUI. This adds an in-app Program Output window that streams the tool's stdout/stderr live while it runs.

Scope: Linux only, for now

The console is wired up only on Linux. On Windows, macOS, the WPF GUI and the CLI nothing changes — the output sink stays null, so the original UseShellExecute launch path is used exactly as before. I kept this conservative for the first cut; if you're happy with the approach, a natural follow-up would be to unify it across all platforms (and drop the separate CMD window on Windows). Happy to discuss.

How it works

• MPF.ExecutionContexts – BaseExecutionContext gains an optional Action<string>? OutputReceived. When set, the tool is started with RedirectStandardOutput/Error and read raw (char-level, carriage-return aware) on two background threads, so \r progress redraws don't flood the log. When null (every current caller), the launch path is unchanged. Kept net20-safe (no Channels/async) for the multi-targeted projects.
• MPF.Frontend – DumpEnvironment.ToolOutputReceived forwards the stream. A minimal IToolOutputConsole seam (Open / Append / NotifyToolExited) lets a frontend present the output without the frontend layer taking a UI dependency. New GuiSettings.ToolConsoleAutoClose option, round-tripped through OptionsLoader.
• MPF.Avalonia – ToolOutputWindow renders the stream in a virtualized, terminal-style view (fixed-height rows, \r/\n line discipline, copy / select-all). Shown modeless and owned beside the main window, so the main window and its Stop button stay fully responsive. An "auto-close when the program exits" checkbox (default on) is persisted to the config.

Localization

New user-facing strings added to Strings.xaml and Strings.de.xaml.

Testing

• Full solution builds clean across all target frameworks (net20 → net10.0): 0 warnings, 0 errors.
• MPF.ExecutionContexts.Test (615) and MPF.Frontend.Test (529) pass with 0 failures on net8.0/net9.0/net10.0.
• Manually verified on Fedora KDE (Avalonia, .NET 10) with real redumper and DiscImageCreator dumps of a PhotoCD disc: live output streams correctly, the window stays responsive, Stop works, and the auto-close preference persists across restarts.

---

Prepared with AI assistance (Claude Opus 4.8) and reviewed before submission.

[gmipf]

Thanks for the review. I've addressed all the points and force-pushed c6fb4d24:

• Rebased onto current master and put the changelog line in a fresh ### WIP section above the released 3.8.2 (this also clears the merge conflict).
• Style: single-line <summary> blocks expanded to multi-line; postfix field comments turned into summaries; braces added to all single-line loops; blank lines added before break/after blocks.
• TerminalBuffer.Feed parameter is now string? to make the null-tolerant contract explicit.
• Replied inline on the three questions (native-console auto-close, pump-thread ordering, macOS scope).

Builds clean with TreatWarningsAsErrors across every target (net5.0–net10.0 for the Avalonia stack, net20–net10.0 for MPF.ExecutionContexts); GUI smoke-tested on Linux. The earlier inline comments will show as outdated because of the rebase.

Generated with Claude Opus 4.8.

[mnadareski]

Just for future reference: you don't need to do a force push to the branch to ensure a clean commit. I squash and merge PRs when they're set. Unfortunately, force pushes make it harder for me to validate any given comment I made, as not just the code I expected to see change is marked as changed.