Verify permission and setup UX on clean accounts and signed releases

[malpern]

Context

KeyPath depends on macOS permissions and service-management state that can be confusing during first run and upgrade: Accessibility, Input Monitoring, Full Disk Access, Login Items, privileged helper registration, and the Kanata launch daemon. The final signed build is healthy on the current machine, but clean-account testing must verify that the app explains permission blockers clearly.

Scope

This is a focused signed-build validation pass, not a redesign task. If testing exposes confusing or incorrect behavior, split that behavior into a concrete issue rather than implementing broad wizard polish here.

Test plan

• Validate first-run setup on a clean account where permissions are not already granted.
• Validate upgrade behavior where permissions are already granted.
• Confirm Input Monitoring denial is detected and explained correctly.
• Confirm Accessibility denial is detected and explained correctly.
• After granting Accessibility or Input Monitoring, confirm KeyPath recognizes the grant without a relaunch when macOS permits it.
• If macOS requires a relaunch before a new grant becomes visible, confirm the wizard offers an explicit Restart KeyPath action instead of polling indefinitely.
• Confirm Login Items/pending approval is represented distinctly from runtime failure.
• Confirm Fix It does not report success unless runtime is healthy or approval is explicitly pending.
• Confirm the status screen gives a concrete next action when macOS blocks setup.

Acceptance criteria

• Permission-related blockers are understandable to a non-developer tester.
• The app does not conflate macOS approval-pending states with internal failures.
• Permission polling either observes the grant or transitions to accurate restart guidance.
• Any confusing or incorrect UX found here gets split into a focused issue.