Fix headless --import crash (Unknown global command type)

[dcwhite]

Summary

• The console (headless) global command factory had no case for GlobalCommands::ImportNetworkFile, so --import crashed immediately with Unhandled exception: Unknown global command type. on any headless build (mac/linux/windows-headless).
• This was invisible until Upgrade GoogleTest to v1.17.0 and fix Windows unit test infrastructure #2535 wired up ctest in CI, at which point it caused ~90% of unit/regression tests to fail identically on headless jobs (every .Test.ImportNetwork.* test uses --import), while GUI builds passed at 97%.
• Adds ImportFileCommandConsole, sharing filename-resolution/parse/load/regression-exit logic with LoadFileCommandConsole via a new NetworkFileProcessCommandConsole base class, mirroring the existing GUI FileImportCommand/NetworkFileProcessCommand split.

Test plan

• windows-build and windows-build-script CI runs pass on this branch
• linux-build CI run passes on this branch (linux-headless, linux-gui, linux-gui-nonpython all green)
• mac CI (only runs on PR) — pending this PR's checks
• Confirm ctest -R ImportNetwork pass rate on headless builds jumps from ~10% to matching the GUI build's ~97%

🤖 Generated with Claude Code

[dcwhite]

Blocked on #2564 — same root cause.

The mac-headless-14-arm and mac-headless-14-arm-slim builds here fail with:

src/Core/ConsoleApplication/ConsoleCommands.cc:116:5: error: use of undeclared identifier 'quick_exit'

quick_exit entered libSystem in macOS 15.0 and isn't declared at all by older SDKs. Reproduced locally against the 13.3 SDK:

spelling	result
std::quick_exit(1)	error: reference to unresolved using declaration
quick_exit(1)	error: use of undeclared identifier 'quick_exit'

So fe316899e's diagnosis was right — libc++'s using-declaration really does fail to resolve. The workaround just doesn't hold, because the global C symbol it falls back to isn't declared either; both spellings are the same missing declaration seen from two sides. (__DARWIN_C_LEVEL is a red herring — it defaults to __DARWIN_C_FULL, so that gate is open.)

#2564 sidesteps this with SCIRun::Core::quickExit() (src/Core/Utils/QuickExit.h), which takes std::_Exit unconditionally on Apple. Verified against both the 13.3 and 15.2 SDKs: compiles clean, and nm -u shows __Exit with no _quick_exit reference.

Plan once #2564 lands: rebase onto master, revert fe316899e, then #include <Core/Utils/QuickExit.h> and call quickExit(1) at ConsoleCommands.cc:116.

Worth doing independently of the build failure: against the 15 SDK the bare quick_exit(1) here compiles fine but emits a hard _quick_exit reference (confirmed via nm -u), which is the dyld load failure #2564 exists to eliminate — it would just move it from libInterface_Application to libCore_ConsoleApplication. Note the trigger is the SDK, not the host OS.

The remaining red on this PR is unrelated — those jobs hit the 24h Actions queue timeout and were cancelled without building.