Guided first-launch walkthrough when keyboard hooks can't start

[vstrelnikof]

When the keyboard hooks fail to start (missing macOS permissions, no evdev access on Linux/Wayland), the tray now shows a "⚠ Setup Guide" alert entry, a tooltip warning and a one-shot notification pointing at docs/PERMISSIONS.md. That stops the app failing silently — but the user still ends up reading a markdown file to fix their setup.

What's missing is a guided walkthrough window:

• macOS: explain Accessibility + Input Monitoring, deep-link straight into the right System Settings panes (x-apple.systempreferences: URLs), show the state, offer "check again". Screenshots/GIFs of the toggle would remove the last confusion.
• Linux (Wayland): explain what scripts/setup-linux.sh does (evdev group + uinput), offer to open a terminal with it / copy the command, and "check again" after re-login. Detect the common half-state where the group is added but the session hasn't picked it up.
• Windows: hooks essentially always start; the window just never shows.
• A persistent, honest banner for the rarer "layout switching unavailable" case (hooks fine, switcher backend not found).

Architecture note: the settings GUI runs as a child process (poltertype --settings) so the tray's event loop and iced's don't fight over the macOS main thread — the walkthrough should be another pane/mode of that child process, launched by the tray alert entry, not a new toolkit surface. See crates/poltertype-app/src/settings_ui/ for the pane pattern.

[vstrelnikof]

Built in PR #17 — a Setup pane in the Settings child process, exactly as
the issue's architecture note asked, launched by the tray alert entry
(poltertype --setup opens the same window directly).

It probes, it does not just explain. poltertype_input::setup::probe_setup
reads the live machine and the pane renders the answer:

• Linux/Wayland — "read the keyboard" and "type the correction" as two
  separate rows, because they are two separate permissions and fail
  separately; the half-granted case (detection works, nothing gets fixed) is
  the one that reads as the app being broken rather than unconfigured.
• Linux/X11 — "nothing to set up", said plainly. Most people arrive
  expecting the worst.
• macOS — Accessibility and Input Monitoring separately, each with a
  button that raises the system's own prompt (AXIsProcessTrusted /
  IOHIDCheckAccess to read state without prompting, so Check again never
  throws a dialog), plus x-apple.systempreferences: deep links for when the
  prompt has already been answered once and macOS will not show it again.
• Windows — says there is nothing to grant. The window never needs to
  appear there, and the tray entry only exists when hooks failed.

The half-state you flagged has its own answer. usermod -aG input writes
the group database and cannot touch a login session that already exists, so
everything looks configured and nothing works — and "re-run the script", the
only advice a two-state model can give, changes nothing. The probe compares
/etc/group against this process's actual credentials and reports log out
instead. There is a fourth state, Unknown, for what genuinely cannot be
determined: a guide that invents a problem loses the reader, and one that
asserts an unverified fix is worse.

Nothing on the pane runs anything privileged. No "Run setup" button: the
script needs sudo, and an app that quietly acquires root on a machine where
it already reads every keystroke has spent trust it will not get back. The
button copies the command; the user reads it and runs it in their own terminal.

The layout-switching banner is in too — hooks fine, no switcher backend is
its own failure, and the visible symptom (corrections rewriting the word into
the same wrong layout) looks like the correction being wrong rather than
missing.

Not done, and still worth doing: the screenshots / GIFs of the macOS
toggles. They would be the most useful part of that pane for a first-time Mac
user, and they cannot be produced without a Mac. The macOS code path here is
compiled by CI and has been run by nobody — same caveat as everything else
Apple-side, see #3.

Design notes in docs/DECISIONS.md (2026-07-31); docs/PERMISSIONS.md now
describes what exists rather than what was planned.