Bug

Selecting a non-local exposure mode (e.g., Tailscale Funnel) during netclaw init causes the health check step (step 10) to fail. ExposureModeValidationService requires at least one paired device or configured auth scheme before the daemon will start, but device pairing requires a running daemon.

This is the bootstrap chicken-and-egg problem: can't pair without a running daemon, can't start the daemon without a paired device.

Steps to reproduce

1. Run netclaw init
2. Select Tailscale Funnel as exposure mode
3. Complete all wizard steps
4. Step 10 (health check) fails — daemon refuses to start

Expected behavior

The wizard should handle the bootstrap case for non-local exposure modes so the daemon can start successfully after init.

Possible solutions

1. Auto-pair the local machine during init — the machine running netclaw init is implicitly trusted; generate a device token for localhost as part of the wizard finalization
2. Bootstrap mode — allow the daemon to start accepting local-only connections until the first device is paired, then enforce the requirement
3. Add a pairing step to the wizard — prompt the user to pair this device between exposure mode selection and health check

Option 1 is likely the cleanest UX — no extra steps, no special modes.

Files

• src/Netclaw.Daemon/Services/ExposureModeValidationService.cs (enforcement)
• src/Netclaw.Cli/Tui/Wizard/Steps/HealthCheckStepViewModel.cs (crash point)
• src/Netclaw.Cli/Tui/Wizard/Steps/ExposureModeStepView.cs (high-risk warning mentions "ensure auth is configured" — also premature)