feat(settings): let permission and iOS location settings target an explicit app #3179

Problem

settings permission (and settings location grant on iOS) act only on the app the session has open. Without one they refuse with INVALID_ARGS 'permission setting requires an active app in session' (Apple, Android). The underlying simctl privacy and Android grant need only the app id. SettingsUpdateOptions has no app field for permissions, although clear-app-state already takes one, and the daemon already resolves an explicit id first (settingsWriteAppId).

Consumer impact: to set a permission before the first launch, tester-army/e2e opens the app first just to bind it to the session. It tracks which app the session is on, lists sessions to recover that after a worker restart, opens the app during warm-up, and matches the refusal text to retry after another open (tester-army/e2e#526, #539).

Required behavior

await client.settings.update({ setting: 'permission', permission: 'camera', state: 'grant', app: 'com.example.app' });

agent-device settings permission grant camera --app com.example.app

• permission (iOS simulator, Android) and iOS location grant/revoke accept an explicit app. Without it, behavior is unchanged: the session's app is used.
• No app needs to be running or open.
• macOS permissions are host-level and keep their permission-target model; app does not apply there.
• The Android revoke rule stays documented: revoking a granted permission kills the app (android: settings permission reset/deny kills the app when the permission was granted — no hint #1796), so callers still set permissions before launch.

Done when

• A permission is set on an app the session has never opened, on iOS simulator and Android.
• The CLI help, the MCP schema and the client types document app for these settings.

From the tester-army/e2e integration review.