Context

The init wizard currently has separate sequential steps for each channel adapter (Slack → Discord → Channels audience editor). As we add more adapters, this becomes a linear slog through steps the user may not care about. Noticed during Discord integration testing in #713.

Proposal

Replace the separate Slack/Discord enable-or-skip steps (currently steps 3–4) with a single Communication Channels picker step. The user selects which channels to connect from a menu, configures each one inline, and explicitly signals "done" before advancing.

UI Preview

Initial state:

  Which channels would you like to connect?

  ▶ [ ] Slack
    [ ] Discord

  ↑/↓ to navigate, Space to toggle, Enter to configure selected.
  [d] Done — continue to next step

After configuring Slack:

  Which channels would you like to connect?

    [✓] Slack                  2 channels configured
  ▶ [ ] Discord

  ↑/↓ to navigate, Space to toggle, Enter to configure selected.
  [e] Edit configured channel    [d] Done — continue to next step

After configuring both:

  Which channels would you like to connect?

    [✓] Slack                  2 channels configured
    [✓] Discord                1 channel configured

  [e] Edit configured channel    [d] Done — continue to next step

Workflow

1. User sees available channel adapters as a checklist
2. Toggling a channel ON immediately flows into its config sub-steps (token, channels, DMs, user IDs, etc.)
3. When sub-steps complete, returns to the picker with a summary (e.g. "2 channels configured")
4. Toggling OFF clears that channel's config
5. [e] on a configured channel re-enters its sub-steps for editing
6. [d] advances to the Channels audience editor (existing step), then the rest of the wizard

Implementation Notes

• The existing SlackStepViewModel and DiscordStepViewModel become sub-step sequences within a new unified ChannelPickerStepViewModel
• The ChannelsStepViewModel (audience editor) stays as-is — it already aggregates across sources
• New adapters just add a row to the picker list; no wizard restructuring needed
• WizardOrchestrator already supports IsApplicable filtering and sub-steps via TryAdvance/TryGoBack, so the infrastructure is in place

Key Files

• src/Netclaw.Cli/Tui/InitWizardViewModel.cs — step registration (lines 96–109)
• src/Netclaw.Cli/Tui/Wizard/Steps/SlackStepViewModel.cs — becomes sub-step sequence
• src/Netclaw.Cli/Tui/Wizard/Steps/DiscordStepViewModel.cs — becomes sub-step sequence
• src/Netclaw.Cli/Tui/Wizard/Steps/ChannelsStepViewModel.cs — unchanged (audience editor)
• src/Netclaw.Cli/Tui/Wizard/WizardOrchestrator.cs — may need minor changes for nested sub-step flows