fix(desktop): inherit app TCC identity in sidecar entitlements

[mattalldianhr]

Fixes #2783.

Problem

Sidecars ship as loose executables in Contents/MacOS/ and are signed with their own code-signing identifiers rather than the app's:

buzz-desktop           Identifier=xyz.block.buzz.app
buzz-acp               Identifier=buzz-acp              ← mismatch
buzz-agent             Identifier=buzz-agent            ← mismatch
buzz-dev-mcp           Identifier=buzz-dev-mcp          ← mismatch
buzz                   Identifier=buzz                  ← mismatch
git-credential-nostr   Identifier=git-credential-nostr  ← mismatch

When a sidecar spawns a subprocess that triggers a TCC-gated access, macOS raises the consent prompt under the sidecar's identity. The user's "Allow" is recorded against xyz.block.buzz.app, so the next request — arriving under a different identity — prompts again, indefinitely.

Observed in the wild: a managed agent under buzz-acp invoking op (1Password CLI, which reads its own group container) produced ~110 consent prompts in 58 seconds. tccd logs DB Action:None on every request — no decision is ever persisted — and Buzz never appears in System Settings › Privacy & Security › Files and Folders, so the permission cannot be granted manually.

op is incidental. Any sidecar-spawned tool that touches another app's data hits this.

Implementation

Add com.apple.security.inherit to Entitlements.plist so child processes adopt the parent app's sandbox/TCC identity, letting a single grant cover the sidecars.

⚠️ Please verify before merging

I could not test this. Verifying it requires a signed + notarized build from the release pipeline, which I can't produce locally. The diagnosis is thoroughly confirmed (see #2783 for the tccd traces and a table of six ruled-out workarounds); the fix is not.

Specifically worth a maintainer's judgement:

1. com.apple.security.inherit is primarily an App Sandbox inheritance mechanism. Buzz is hardened-runtime but not sandboxed, so it may be a no-op here.
2. The more robust fix may be to sign the sidecars with the app's identifier (--identifier xyz.block.buzz.app) in block/apple-codesign-action, rather than relying on entitlement inheritance.
3. If inherit is honored, it may require the sidecars to also carry it, or to be signed as part of the parent bundle.

I'd suggest whoever owns the signing pipeline confirm which mechanism applies before this ships. Happy to close this in favour of a pipeline-side fix.

How to test

On a signed build:

1. Configure a managed agent that shells out to a tool reading another app's container (e.g. op read).
2. Run the agent; click Allow once at the prompt.
3. Expected: no further prompts, and Buzz appears in Privacy & Security › Files and Folders.
4. Pre-fix: the prompt recurs on every invocation and Buzz never appears in that list.