Finish v1 → v2 migration

bash migrate-v2.sh already ran the deterministic migration. It handled:

• .env keys merged
• v2 DB seeded (agent_groups, messaging_groups, wiring)
• Group folders copied (v1 CLAUDE.md → v2 CLAUDE.local.md)
• Session data copied with conversation continuity (incl. Claude Code memory + JSONL transcripts)
• Scheduled tasks ported
• Channel code installed and auth state copied (incl. WhatsApp Baileys keystore)
• WhatsApp LIDs resolved from store/auth and aliased into messaging_groups
• Container skills copied
• Container image built

Your job is the parts that need human judgment: triage failed steps, seed the owner, run the shared-memory migration, reconcile configs, and port fork customizations.

Read logs/setup-migration/handoff.json first, it has overall_status, per-step results in steps, and a followups list.

Preflight: was the script run?

Before anything else, check that logs/setup-migration/handoff.json exists. If it doesn't, the user is invoking this skill before migrate-v2.sh ran. Stop and tell them, verbatim:

This skill finishes a migration that migrate-v2.sh started. Run that first, in your terminal, not from inside Claude:

bash migrate-v2.sh

It needs interactive prompts (channel selection, service switchover) and runs Node/pnpm bootstrap, Docker, OneCLI setup, and a container build that don't fit inside a Claude session. When it finishes, it'll hand control back to Claude automatically, at which point this skill picks up.

Do not attempt to run the script yourself, simulate its effects, or pick up the migration mid-stream. The deterministic side has dependencies on a real interactive shell.

Once handoff.json exists, proceed to Phase 0.

Phase 0: Get v2 routing real messages

Before any deeper migration work, prove v2 actually answers messages on the user's real channels. v1 is paused, not touched, flipping back is a service restart.

0a, Fix blockers only