feat(setup): two-step wizard

[Behnam-RK]

Stacked on #51 → #50 → #49.

Implements the two-step shape you described: step 1 countries, step 2 an automatic-detection tickbox that reveals the self-hosted options when unticked, with configureVPN dropped.

The shape

dezhban setup --questions now emits exactly:

blockedCountries | group 1 | multiselect | gate —
otherCountries   | group 1 | list        | gate —
autoMode         | group 2 | bool        | gate —
tunnels          | group 2 | multiselect | gate autoMode=false
profileFiles     | group 2 | list        | gate autoMode=false
endpoints        | group 2 | list        | gate autoMode=false

Both wizards read this one set, so dezhban setup changes with the app.

Dropping configureVPN needed two guards

That question was what kept a re-run from touching a working VPN config (Apply returned early when it was false). Removing it means a run always writes the VPN keys, so:

1. autoMode's default is seeded from the config. A config with pinned vpn.tunnelInterfaces starts on manual. Without this, a re-run would default to automatic, and Apply clears TunnelInterfaces under AutoMode on purpose — so pressing Enter through the wizard would have silently unpinned interfaces someone chose deliberately. Pinned by TestAutoModeSeedsFalseWhenInterfacesArePinned on both sides.

2. Input.Endpoints becomes *[]string, nil when the question was never shown. On macOS the endpoint question is gated behind "not automatic", so someone re-running setup to change their blocked-country list — leaving detection on, as recommended — reaches Apply with no endpoint answer at all. Writing that as an empty list would delete their server. Nil rather than empty for exactly the reason the existing AutoDiscover *bool is a pointer, and its doc comment already says so: an empty slice cannot be told apart from "asked, and cleared on purpose". The Swift side already had this property for free via shouldAsk.

One thing worth flagging

Off macOS the endpoint question is ungated. There is no live discovery on Linux or Windows, so an endpoint is required whichever detection mode is chosen — gating it would let a Linux user finish the wizard with a config that cannot enforce. TestEndpointsAreUngatedWhereThereIsNoDiscovery pins it.

The CLI renders step 2 as two prompts

A huh form binds every field before any of them is answered, so a question gated on another question in the same group would be decided by that question's seeded default rather than by what the user just ticked. The app has no such problem — it re-evaluates gates as answers change, which is what makes step 2 a single screen there.

Rather than split the shared question set to suit one renderer, the terminal now asks a group in waves: the ungated questions first, then re-evaluate, then whatever that opened up. Documented in cli.md so the difference is not a surprise.

Verification

• go build ./..., go vet ./..., go test ./... — pass. internal/setup gains five tests: the two-group shape across all three platforms, the pinned-interface seed both ways, the unasked-endpoint rule, the gating, and the off-macOS ungating.
• swift test — 199 tests pass. The SetupQuestionsTests JSON fixture is updated to the real emitted shape, and gains theWizardIsTwoSteps, anUnaskedQuestionWritesNoKey, and aSeededManualModeReWritesItsPins.
• dezhban setup --questions output inspected directly (above).

On-host checks added to docs/contribute/testing.md, the important two being: a re-run on a pinned config keeps its pins, and a re-run under automatic detection keeps configured endpoints. Also fixes a stale defaults delete com.dezhban.menu in the first-run checklist — that domain has been com.behnam-rk.dezhban.app for a while.

🤖 Generated with Claude Code