Add macOS Contacts and Apple Events entitlements to desktop app

[chakshu-dhannawat]

Closes #10286

The problem

The desktop app's forge.config.ts and entitlements.plist declare Info.plist usage descriptions and sandbox entitlements for Calendars and Reminders, but never added the matching ones for Contacts.

Without NSContactsUsageDescription, macOS won't even show the permission prompt, it just fails silently. Same for NSAppleEventsUsageDescription, needed for any Apple Events automation of another app (for example, driving Contacts.app to edit a contact's notes field, which isn't exposed through the regular Contacts API). com.apple.security.automation.apple-events was already present in entitlements.plist, it was just missing its Info.plist usage-description counterpart, so that half of the permission never worked either.

I hit this the same way the issue reporter did: an extension that reads/edits Contacts silently fails on the desktop app with no permission prompt ever shown.

The fix

Added both Info.plist keys to forge.config.ts and the one missing sandbox entitlement to entitlements.plist, following the exact pattern already used for the Calendars/Reminders keys in the same files. No other code paths touch these files (checked, nothing in src/ references the entitlement/usage-description strings), so this is a self-contained config change.

[alexhancock]

goose first party code doesn't need this entitlement, so I hesitate to grant an approval immediately on this. The UX shown in the screenshot where the agent instructs the user how to grant permission to do what they are asking seems right to me if the needed access is in third party extensions to goose. It looks to me upon review we have other entitlements listed which first party code doesn't need. I am going to look into this with the other core maintainers and get back to you.

[alexhancock]

Thanks for digging into this and for the clear write-up — you correctly identified a real inconsistency in our entitlements.

After reviewing with the entitlements as a whole, we've decided to go the other direction: goose's first-party code doesn't use Contacts (or several other capabilities we were already declaring), and we'd rather the signed desktop app only declare entitlements our own code actually needs. When a third-party extension needs Contacts access, the right pattern is the one shown in your screenshot in #10286 — the agent guiding the user to grant that permission — rather than the core app broadly declaring it.

I've opened #10490 to trim the entitlements we don't need first-party (removing Contacts, Calendars, Reminders, screen-recording, and camera) and to add the missing microphone and Apple Events usage descriptions for the capabilities we do use. Because of that direction, I'm going to close this PR.

For your Contacts-editing extension use case, this is worth continuing in #10286 — let's figure out the right supported path for extensions that need entitlements the core app doesn't ship. Really appreciate the contribution.

I've opened this PR #10490 for now.