feat: complete uninstall and purge

[Behnam-RK]

Stacked on #50 (which is itself on #49). Review those first; this PR's diff is against #50.

This also fixes the "setup flow didn't auto-start on first run" report — the two turned out to be the same defect seen from opposite ends.

The diagnosis

FirstRunDecision.offer is !isComplete && !vpnKnown, where isComplete reads dezhban.firstRunCompleted from the app's preference domain. On the machine where this was investigated:

$ defaults read com.behnam-rk.dezhban.app
{ "dezhban.firstRunCompleted" = 1; ... }
$ python3 -c "..." /etc/dezhban/dezhban.json
endpoints: []   profiles: []

The daemon side had been reset; the per-user flag had not, because packaging/macos/uninstall.sh runs as root and only ever removed root-owned state. So a reinstalled machine with no VPN configured still answered "the wizard has been completed" and stayed silent.

defaults domains also showed a second, dead domain — com.dezhban.DezhbanMenu, from a superseded bundle identifier — that nothing had ever cleaned up.

The keychain control token and the login-item registration survived uninstall the same way. A surviving login item makes macOS keep trying to launch a deleted bundle.

Why the app has to do it

Root cannot. A login-keychain item's ACL is bound to the user's session, and a login item is registered per user via SMAppService. sudo -u into an account that is not logged in cannot unlock its login keychain. So the work is split by who is actually able to perform it.

What changed

Purge.swift (new) removes, in this account's own session: the control token and its capability-probe item (via a new ControlToken.purge(), which owns the account names and the -25244 ACL reason a plain SecItemDelete will not work), both login-item registrations (the ADR-0014 agent and any surviving mainApp one), the saved-window-state directories, and the preference domains — current and legacy.

Preference domains go last, immediately before NSApp.terminate: AppKit writes defaults as the app winds down, so a domain cleared early would simply be recreated before the process exits.

Settings → Remove Dezhban… is a critical-style alert naming every category it removes, with a "Keep my dezhban configuration in /etc/dezhban" checkbox mapping to the script's existing KEEP_CONFIG=1. Cancel is the default button and the return key cannot trigger removal — the return key must not be able to uninstall a kill switch.

It then opens Terminal.app on sudo sh /usr/local/share/dezhban/uninstall.sh and quits. Not an in-app progress sheet: the script quits Dezhban and deletes its bundle partway through, so a sheet dies mid-teardown and leaves the user unable to tell a finished uninstall from one that stopped after panic removed the rules. A terminal window outlives the app and shows the rule teardown — for a kill switch, the step you most want to watch succeed. If Terminal cannot be opened, the app says dezhban is still installed and still enforcing, prints the command, and does not quit.

uninstall.sh additionally deletes both preference domains for $SUDO_USER (belt and braces, for the shutdown-rewrite reason above, and so a CLI-only install is not left behind), and prints the two per-user items it cannot reach with the commands that finish the job. Only $SUDO_USER, never a loop over /Users — a script that deletes other people's data because root ran it is a scope no uninstaller should claim. Its existing ordering invariant is untouched: panic still runs first.

Rationale

ADR-0015 records what purge destroys, what it deliberately does not (other accounts; notification authorization, which macOS owns and offers no API to revoke), and why the three rejected alternatives were rejected — including "just drop isComplete from the gate", which fixes the symptom in one line and leaves every other item behind.

Verification

• go build ./..., go vet ./..., go test ./..., shellcheck — pass.
• swift test — 197 tests pass.

The purge itself is destructive and one-way, so it is verified on-host rather than in CI. docs/contribute/testing.md gains a "Remove Dezhban (complete purge)" section covering: Cancel as the default; that the keychain item, login item and preference domains are actually gone afterwards; that panic is visible in the transcript before anything is deleted and the network works throughout; KEEP_CONFIG both ways; that a reinstall then opens the first-run wizard; that a missing uninstaller degrades honestly; and that the script's own per-user pass touches only the invoking account.

docs/usage/troubleshooting.md gains two entries: "I reinstalled, but the setup wizard never appears" (with the one-line defaults delete, and a pointer to Settings → Run Setup Again… as the route that needs no uninstall) and "Removing dezhban completely".

🤖 Generated with Claude Code