fix: set permissionMode when --yolo flag is used

[AndyWendt]

Summary

Fixes #206 - 'yolo' mode not sticking in happy app

This PR contains two related fixes:

Fix 1: Set options.permissionMode when --yolo flag is used

The --yolo flag only passed --dangerously-skip-permissions to Claude CLI but did not set options.permissionMode internally. This caused the PermissionHandler to stay in "default" mode.

// Before: only passes CLI flag to Claude
} else if (arg === '--yolo') {
  unknownArgs.push('--dangerously-skip-permissions')
}

// After: ALSO sets internal permissionMode
} else if (arg === '--yolo') {
  unknownArgs.push('--dangerously-skip-permissions')
  options.permissionMode = 'bypassPermissions'
}

Fix 2: Preserve CLI permission mode when mobile sends "default"

When the CLI is started with --yolo, messages from the mobile app with permissionMode: "default" would override the CLI's setting. Now the CLI's explicit mode is preserved unless the mobile explicitly chooses a different mode.

// If CLI was started with --yolo, don't let "default" messages override it
if (cliPermissionMode && incomingMode === 'default') {
    messagePermissionMode = cliPermissionMode;
}

Test Plan

• Built and installed CLI locally from v0.13.0 + fix
• Started happy --yolo
• Verified "bypass permissions on" shows in status bar
• Sent command from mobile app (with default permission mode)
• Confirmed tool executes without permission prompt
• Session runs successfully

Notes

• Based on v0.13.0 tag for testing, but PR targets main
• The fix applies cleanly to both v0.13.0 and current main
• Previous attempt in PR feat: New Session Page w/ one touch Profiles, adds z.ai / deepseek / microsoft AI Backend Support #272 #86 tried a more complex solution

Related

• Closes #206

[AndyWendt]

I branched off of v0.13.0 because main didn't appear to be working. There's a delta here.

I tested on mac / android