Dead-code audit: unreferenced private members + 2 wiring findings (Roslyn sweep)

[anagnorisis2peripeteia]

Summary

I ran the Roslyn code-style analyzers (EnforceCodeStyleInBuild=true) across the full
DS4WinWPF project to find demonstrably-dead code — members the compiler confirms are
referenced nowhere in the compilation. This issue tracks a small cleanup series and raises two
findings that look like latent wiring bugs rather than cruft, so I'd like your call before
touching them.

What the sweep found (main project, current main)

Diagnostic	Count
IDE0051 unused private member	59
IDE0005 unused using directive	~158
CS0414 / CS0169 / CS0168 dead fields/locals	~8

Planned PRs (small, single-purpose)

1. Remove unreferenced private members (opening now) — 53 whole-declaration removals: the
   private pass-through getters in DS4StateExposed, dead named constants across the device
   classes, and orphaned private helper methods. Pure deletion; compiles clean on x64 and
   x86; DS4WindowsTests identical to baseline.
2. Remove unused using directives — mechanical, validated on x64/x86/Debug (follow-up).
3. Assigned-but-never-read fields — need call-site edits, so kept separate (follow-up).

Kept as separate PRs so the mechanical cleanup stays trivially reviewable and anything
behaviour-adjacent gets its own scrutiny.

Two findings I'd like your steer on (I am not deleting these)

While reading the "unused" members, two turned out to look like lost wiring rather than
dead code — deleting them would quietly cement a regression, so I've held them out of the
cleanup:

1. MainWindow.AutoProfVM_AutoProfileSystemChange — subscription commented out. The handler
   is unreferenced only because its subscription is commented out at MainWindow.xaml.cs:433:

   //autoProfControl.AutoProfVM.AutoProfileSystemChange += AutoProfVM_AutoProfileSystemChange;

   …while AutoProfilesViewModel still raises AutoProfileSystemChange (11 call sites). So the
   view-model fires "auto-profiles toggled by the system" and MainWindow no longer reacts.
   Was this disabled on purpose, or is it a regression worth re-wiring?

2. ControlService.WarnExclusiveModeFailure — never called. A fully-implemented user
   warning ("Could not open DS4 — quit other programs") shown when an exclusive-mode open fails.
   The failure path in DS4Devices.cs and the CouldNotOpenDS4 resource string both still
   exist; only the call that warns the user is gone. Intentional, or a lost diagnostic worth
   restoring?

Happy to send follow-up PRs for either if you'd like them re-wired.

Analysis and drafting assisted by Claude (Opus 4.8).