feat(gui)!: replace the terminal interface with an egui desktop window

[SecretLUL]

What this changes

WinMedic's interactive front end moves from a ratatui terminal interface to an
egui/eframe desktop window. src/ui/ is deleted, src/gui/ takes its place, and
the TUI is not kept behind a flag.

Almost nothing else had to move. App was already pure state with no ratatui in
it, the engine already reported over channels any front end can drain, and exactly
one line outside the render layer named a UI library — the
crossterm::event::KeyCode import in app::input. That is now a toolkit-neutral
Key enum which the front end translates egui's events into, so the whole layered
dispatch table and its tests survived unchanged. src/app/, src/engine/,
src/modules/, src/safety/ and the headless CLI are untouched apart from stale
comments.

Three decisions worth reviewing on their merits:

• The binary stays in the console subsystem. #![windows_subsystem = "windows"]
  would buy a GUI that never flashes a console and pay for it by breaking every
  headless guarantee: a Windows-subsystem process does not hold the shell, so
  winmedic --json > out.json returns before the file is finished, the documented
  exit codes arrive after whatever ran next, and release.yml can no longer
  capture winmedic.exe --version into the variable it compares against the tag.
  utils::console hands the console back at GUI start instead, and only when
  GetConsoleProcessList says this process is alone in it. The cost is a console
  window visible until main is reached.
• One binary, not two. A separate console executable was the obvious
  alternative and was rejected because swap_in_place in utils::self_update is
  built around updating exactly one file, with one checksum and one signature.
• MSRV 1.88 → 1.95. The old floor came from ratatui → instability → darling
  and left with ratatui; egui 0.36 sets the new one. Verified against a real 1.95
  toolchain, not assumed.

Three pieces of state stopped being reachable once the drawing changed, and are
handled rather than left dangling: the log scroll keys and their offsets are gone
because the consoles are scroll areas now; / no longer switches on a
character-capture mode, since a window has a real text field bound to the same
string; and the settings pane now draws which row is selected and which of its two
lists owns the arrow keys, both of which the keyboard moves and neither of which
was visible.

Dropping ratatui also clears the three RUSTSEC advisories the audit job's comment
documented as unfixable (paste, 2× lru). cargo audit now reports nothing.

Related issue

None.

Does it change what WinMedic does to a system?

• No — documentation, CI, tests or refactoring only

No diagnostic or repair logic changed. Every module, every fix path, the audit
log, the registry backups and the restore-point handling are byte-identical; what
changed is which pixels the same state is drawn as.

Checks

• cargo fmt -- --check
• cargo clippy --locked --all-targets -- -D warnings
• cargo test --locked — 549 tests
• New behaviour is covered by tests using MockCommandRunner, not real commands

The nine ratatui render tests become nine egui_kittest tests asserting against
the accessibility tree, which is the more honest target: a label missing from it is
missing for a screen reader, not merely for a test.

What was verified, and how

Windows 11 26200, Rust 1.98.1, MSVC toolchain.

• cargo fmt -- --check, cargo clippy --locked --all-targets -- -D warnings
  clean; 549 tests pass.
• cargo audit clean against the new lock file.
• cargo +1.95 check --locked --all-targets passes, so the declared MSRV is real.
• cargo build --locked --release (LTO, panic = "abort") links, and the release
  binary opens its window and closes cleanly.
• Headless contract exercised against the release binary:
  winmedic.exe --version is capturable into a shell variable (this is the exact
  step release.yml performs), and --json --scan delivers 135 KB of valid JSON
  through a pipe with exit code 2.

Four defects were found by that verification rather than by the compiler, and are
fixed here: the settings pane's focus hint used the arrow glyphs the terminal
version had and all three rendered as empty boxes, because egui bundles a Latin
text face; the confirmation dialog's primary button drew dark text on a dark
surface; the selected setting row and the arrow-key focus were invisible; and /
was handling keystrokes twice. every_character_the_window_draws_has_a_glyph
guards the first of those, and was itself checked by reintroducing the defect and
confirming it goes red — the first version of that test passed while the bug was
still on screen, because it read AccessKit's label and static text lives in
value.

Honest gaps. No full scan has been driven through the window end to end; the
Health Scan and Repair Center tabs are covered by tests with realistic run state
(a failed module, a partial repair pass, console output), but nobody has watched a
real scan progress in the GUI. The release binary grew to 7.9 MB from the bundled
fonts and the OpenGL renderer.

🤖 Generated with Claude Code