settings permission --app writes a display name as the bundle id instead of resolving it #3384

Problem

settings permission … --app <name> (#3179) passes the app through unresolved. On iOS it goes straight to simctl privacy; on Android it goes to pm grant or pm revoke. A display name is never resolved to its bundle id or package. settings clear-app-state --app, open and close all resolve it.

Live on 0.21.22 (iOS 27.1 simulator):

agent-device settings permission grant photos --app Maps --platform ios --udid <udid>
# Updated setting: permission

The simulator's TCC.db then has a kTCCServicePhotos row for client Maps, not com.apple.Maps. The real app never gets the permission, and the command reports success. settings clear-app-state --app Maps on the same device resolves to com.apple.Maps ("bundleId": "com.apple.Maps").

Consumer impact: tester-army/e2e pins apps by whatever app accepts, including display names (its quickstart uses bundleId: 'Settings'). To drop its "open the app first so the session names it" workaround, it needs --app on permissions to accept what open --app accepts.

Required behavior

• An app-scoped settings mutation (permission, and iOS location grant/revoke) resolves an explicit app the way clear-app-state does: a bundle id or package passes through, and a display name resolves to the installed app's id.
• An app that resolves to nothing is refused before anything is sent, with details.dispatched: 'no'. It is never written as a literal client id.

Done when

• Tests on both platforms: a display name resolves to the id that reaches simctl privacy or pm, and an unknown app is refused.
• Live on an iOS simulator: settings permission grant photos --app Maps writes the TCC.db row for com.apple.Maps.

Related: #3179.