Hoist machine orchestration out of EmulatorShell into a core Machine/System class (+ close exe UT gap)

[relmer]

Problem

The Casso.exe project has drifted from the intended "insanely light shim" model. Measured source lines (excluding build output and vendored External/):

Project	Lines
Casso (exe)	34,875
CassoEmuCore	16,757
CassoCore	8,058
cores combined	24,815

The exe is larger than both core libs combined. Most of that is defensible platform code — Ui/ (dxui + DirectX presentation, 16.1k), Config/ settings UI (2.85k), D3D/CRT/WASAPI/debug-dialogs (~3.3k) — which correctly does not belong in a portable/testable core.

The genuine divergence is a god-object: EmulatorShell.cpp/.h (~5,264 lines) mixes the Win32 window with machine lifecycle, CPU-thread orchestration, soft-switch state, and video-mode selection. Shell/MachineManager does machine construction. That orchestration is platform-agnostic and belongs in core, where a headless test harness (or a future C64/NES frontend) could drive it.

Why it matters

There are no unit tests for anything in the exe, because the UnitTest DLL only links CassoCore/CassoEmuCore, and there is no headless Machine/System façade in core to test against. The missing abstraction and the missing test coverage are the same hole. This is now codified as Constitution Principle VI (Thin Executable, Testable Core), which existing exe code violates.

Proposed direction (separate from feature work)

• Extract a core Machine/System class: build-a-machine, step the CPU thread, hold soft-switch state, reset/power-cycle. EmulatorShell becomes a thin Win32 driver over it.
• Audit other likely leaks: TrackSectorPredicate, parts of AssetBootstrap.
• Backfill unit tests against the extracted core orchestration.

Non-goals

Not to be folded into feature branches. New feature code already follows the target split (logic core-side + tested, exe limited to irreducible platform edges); the EmulatorShell extraction itself is its own effort.