Set a terminal type for dumping tools when their output is not a terminal

[gmipf]

Problem

Aaru 5 queries the console width (Console.WindowWidth) while drawing progress. When its standard output is not a terminal, that width can only come from the TERM/terminfo fallback, and when TERM is unset it comes back as 0. Aaru 5 then evaluates new string(' ', width - 1) and throws ArgumentOutOfRangeException on the very first progress update, before it reads a single sector.

MPF hands Aaru 5 a non-terminal stdout in two independent situations:

1. GUI — the Linux tool-output console (added in Add live tool output console for the Linux GUI #998) redirects the tool's stdout to a pipe so it can be shown in a window.
2. CLI — MPF.CLI launches the tool with UseShellExecute = true, so the tool inherits MPF.CLI's own stdout. When MPF.CLI itself runs without a terminal (a script, a service, cron, or mpf-cli … > log), the tool inherits that non-terminal. This path predates Add live tool output console for the Linux GUI #998 and is not specific to the GUI.

Whether it bites also depends on the environment's TERM:

Launched from	TERM seen by the tool	Aaru 5 result
GNOME menu (GNOME Shell 50.1)	(unset)	aborts before first read
KDE Plasma menu	dumb (has a terminfo width)	dumps fine
a terminal	xterm etc.	dumps fine

So from GNOME — or any environment that does not export TERM, including non-interactive service/cron contexts — Aaru 5 cannot dump at all, while the same build works from KDE or a terminal.

Fix

When the tool's stdout will not be a terminal and the environment has no TERM, set TERM to a type with a known width. This covers both the redirected (GUI) path and the inherited-output (CLI) path. A real terminal's TERM is left untouched. The inherited-output check is limited to .NET 5+ on non-Windows: TERM is meaningless on Windows, and there an environment entry cannot be combined with UseShellExecute.

#if NET5_0_OR_GREATER
bool inheritsRedirectedOutput = !redirect && !OperatingSystem.IsWindows() && Console.IsOutputRedirected;
#else
bool inheritsRedirectedOutput = false;
#endif

if ((redirect || inheritsRedirectedOutput)
    && string.IsNullOrEmpty(Environment.GetEnvironmentVariable("TERM")))
{
    startInfo.EnvironmentVariables["TERM"] = "xterm";
}

Testing

Measured on real hardware (Plextor PX-760A, audio CD) in a clean VM, driving the real BaseExecutionContext.ExecuteInternalProgram path with TERM unset (the GNOME / service condition). Images are time-boxed, so sizes are not comparable between tools:

Tool (via MPF.CLI, TERM unset, no terminal)	before	after
Aaru 5.4.2	ArgumentOutOfRangeException, no image	dumps (≈102 MB)
redumper	dumps (≈229 MB)	dumps (≈229 MB)
DiscImageCreator	dumps (≈61 MB)	dumps (≈61 MB)
Aaru 6.0.0-beta.1	not invokable by MPF today¹	not invokable by MPF today¹

• Only Aaru 5 is affected: redumper and DiscImageCreator are native tools that do not use the managed console-width API, and they are unchanged by this PR.
• ¹ MPF invokes Aaru with 5.x syntax (--verbose True media dump …); Aaru 6 rejects it at parse time (Unexpected option 'verbose'), so it never reaches this code. Mentioned only for completeness.
• The CLI path is pre-existing: I built MPF.CLI at the commit just before my first contribution and reproduced the identical crash (ArgumentOutOfRangeException → Aaru.Progress.ClearCurrentConsoleLine()) under the same condition, and confirmed it dumps with TERM=xterm. This change does not introduce the CLI behavior; it fixes it.
• Builds across the full TargetFrameworks set (net20 … net10.0) with no warnings; MPF.ExecutionContexts.Test 615 passed and MPF.Frontend.Test 562 passed.

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

[gmipf]

I've expanded this PR. The original commit fixed the GUI console path (#998); I then found the same Aaru 5 crash on the MPF.CLI path, which is independent of #998 and long-standing (the tool inherits MPF.CLI's stdout via UseShellExecute). Rather than open a second PR touching the same lines, I extended the fix here to cover both and updated the title and description accordingly. Everything is measured on real hardware in a clean VM across all four dumping tools; details are in the updated description.

Generated with Claude Opus 4.8.