Wizard never proactively detects pre-MAL-57 VHID daemon plists (missing ProcessType=Interactive)

[malpern]

Follow-up from #882 (MAL-57 Layer 1).

ServiceHealthChecker.isVHIDDaemonConfiguredCorrectly() now requires ProcessType=Interactive in /Library/LaunchDaemons/com.keypath.karabiner-vhiddaemon.plist, but it is only consumed by the repair postflight (ServiceBootstrapper.repairVHIDDaemonServices), where it trivially passes because repair just rewrote the plist.

Nothing feeds plist-content validation into the wizard's health model: getServiceStatus() computes vhidDaemonServiceHealthy from launchctl runtime state only, and SystemInspector.appendComponentIssues() never emits the (defined but dormant) vhidDaemonMisconfigured issue. Users who installed before #882 keep the stuck-key starvation bug until some unrelated event triggers a VHID repair.

Wanted: wire isVHIDDaemonConfiguredCorrectly() into SystemContext.components / SystemInspector so a stale plist surfaces as a wizard issue with auto-fix routing to the existing VHID repair (which rewrites the plist unconditionally).

Cautions:

• isServiceHealthy has a test-mode path that treats plist-existence as healthy; wizard/validator test fixtures will need updating (writeVHIDPlist(programPath:processType:) helper already exists in ServiceHealthCheckerTests).
• Respect ADR-026 validation ordering and keep SMAppService.status out of hot paths.

Evidence and full causal chain: docs/bugs/MAL-57-duplicate-keypresses.md (2026-06-10 Incident Evidence section).

[malpern]

Confirmed worse than initially scoped: keypath system install (full InstallerEngine path) also skips the VHID plist rewrite when services report healthy — verified on a live machine right after #882 was deployed: install reported success, kanata restarted, but /Library/LaunchDaemons/com.keypath.karabiner-vhiddaemon.plist still lacks ProcessType and the daemon kept its old pid. So neither repair nor install migrates existing machines; the wizard health model is the only viable trigger.

[malpern]

Shipped in #904: ComponentInstallationFacts now validates the installed VHID daemon plist content (cached, off the hot path), SystemInspector surfaces the dormant vhidDaemonMisconfigured issue with one-click repair routing, and both repair and install paths converge via vhidRuntimeServicesNeedRepair — with a stale-helper fallback so old helpers can't loop forever. Existing installs now migrate to the MAL-57 ProcessType fix through the wizard instead of a manual sudo one-liner.