#13696: feat(cli): add --code option for WhatsApp pairing code login

## Summary Adds support for pairing code authentication as an alternative to QR code scanning when linking WhatsApp accounts via the CLI. ## Usage ```bash # With phone number openclaw channels login --code --phone +1234567890 # Interactive (prompts for phone number) openclaw channels login --code ``` ## Changes - `src/cli/channels-cli.ts` — Add `--code` and `--phone` options to login command - `src/cli/channel-auth.ts` — Pass new options to plugin - `src/channels/plugins/types.adapters.ts` — Extend ChannelAuthAdapter type - `extensions/whatsapp/src/channel.ts` — Handle useCode in auth.login - `src/web/login.ts` — Implement pairing code flow using Baileys `requestPairingCode` - `src/web/login.pairing-code.test.ts` — Unit tests ## How It Works When `--code` is specified: 1. User provides phone number (via `--phone` or interactive prompt) 2. Socket connects to WhatsApp without showing QR 3. `requestPairingCode()` is called with the phone number 4. 8-digit pairing code is displayed in terminal 5. User enters code in WhatsApp app: Settings → Linked Devices → Link with phone number ## Use Cases - **Headless servers** — No display for QR code scanning - **Remote access** — SSH sessions where QR display is impractical - **Automation** — CI/CD pipelines that need to link accounts - **Accessibility** — Alternative for users who can't scan QR codes ## Testing - ✅ Build passes - ✅ Lint passes - ✅ 6 unit tests pass ## Related This implements the CLI side of the pairing code feature. Related to PRs #8409 and #11484 which add pairing code to the web/onboarding UI. <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR adds pairing code authentication as an alternative to QR code scanning for WhatsApp account linking via the CLI. The implementation threads new `--code` and `--phone` options through the CLI layer (`channels-cli.ts`, `channel-auth.ts`), extends the `ChannelAuthAdapter` type, and updates the WhatsApp plugin to pass these options to `loginWeb`. **Key changes:** - Added `--code` flag to use pairing code instead of QR - Added `--phone` option to provide phone number (or prompts interactively) - Modified `loginWeb` to call Baileys' `requestPairingCode()` when `useCode` is enabled - Added comprehensive unit tests covering phone normalization and flow variations - Proper integration with existing error handling for code 515 restarts **Minor improvements suggested:** - Phone number normalization could be more robust (handle dashes, parentheses) - Consider using `readline/promises` for consistency with existing code patterns - The 1500ms socket initialization delay could be replaced with event-based waiting if possible Overall the implementation is sound and well-tested. The feature properly integrates with the existing authentication flow and maintains backward compatibility. <h3>Confidence Score: 4/5</h3> - This PR is safe to merge with minor style improvements suggested - The implementation is well-structured with comprehensive tests and proper error handling. The feature threads cleanly through the existing architecture without breaking changes. Minor style inconsistencies (readline API usage, phone normalization) don't affect functionality. The hardcoded delay is a slight concern but appears to work in practice based on passing tests. - No files require special attention - all changes are straightforward feature additions <!-- greptile_other_comments_section --> <!-- /greptile_comment -->