[Bug] macOS: sidecar code-signing identifier mismatch causes an unkillable TCC consent loop — Buzz never appears in Privacy & Security

## Summary

On macOS, sidecar binaries in `Contents/MacOS/` are code-signed with their **own** identifiers instead of the app's, and the bundle lacks `com.apple.security.inherit`. When a sidecar (e.g. `buzz-acp`) 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.

The result is an unkillable consent loop: the dialog reappears indefinitely, and **Buzz never appears in System Settings › Privacy & Security › Files and Folders**, so there is no way to grant the permission persistently.

## Evidence

Every sidecar has a distinct signing identifier:

```
$ for b in buzz-desktop buzz-acp buzz-agent buzz-dev-mcp buzz git-credential-nostr; do
codesign -dv /Applications/Buzz.app/Contents/MacOS/$b 2>&1 | grep -oE "Identifier=[^ ]+"; done

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
```

`desktop/src-tauri/Entitlements.plist` does not contain `com.apple.security.inherit`, so children do not adopt the app's TCC identity.

## Reproduction

1. Configure a managed agent that shells out to a tool which reads another app's container. In my case the agent calls `op` (1Password CLI), which reads `~/Library/Group Containers/2BUA8C4S2C.com.1password`.
2. Let the agent run.
3. macOS shows **"Buzz would like to access data from other apps."**
4. Click **Allow** (or **Don't Allow**) — the prompt returns on the next invocation, indefinitely.

Observed ~110 prompts in 58 seconds while an agent was active.

`tccd` attributes the request to the sidecar while naming Buzz as responsible:

```
Handling access request to kTCCServiceSystemPolicyAppData,
from Sub:{xyz.block.buzz.app}
Resp:{... responsible_path=/Applications/Buzz.app/Contents/MacOS/buzz-desktop,
binary_path=/opt/homebrew/Caskroom/1password-cli/2.32.0/op},
ReqResult(Auth Right: Unknown (Service Policy), promptType: 1, DB Action:None)
```

`DB Action:None` on every request — no decision is ever persisted.

## Not a 1Password-specific bug

`op` is incidental. I verified by measuring TCC events per invocation that this is **not** fixable from the credential tool's side — all of these still produce 2 TCC events per call:

| Attempt | `op` works | TCC events |
|---|---|---|
| Baseline | yes | 2/call |
| `OP_BIOMETRIC_UNLOCK_ENABLED=false` | yes | 2/call |
| Cleared `system_auth_latest_signin` in `~/.config/op/config` | yes | 2/call |
| `OP_CONFIG_DIR` pointed at a socket-free dir | yes | 2/call |
| Removed `~/.config/op/op-daemon.sock` | yes | 2/call |
| All combined + explicit `--account` | yes | 2/call |

The same `op` invocation from a terminal also generates 2 TCC events per call but produces **no prompts**, because the terminal has a persisted grant. The access is normal; the missing grant is the bug.

Any agent shelling out to any tool that touches another app's data will hit this — `op` is just the first example.

## Suggested fix

Add `com.apple.security.inherit` to `desktop/src-tauri/Entitlements.plist` so sidecars inherit the app's sandbox/TCC identity:

```xml
com.apple.security.inherit

```

Signing the sidecars with the app's identifier (rather than per-binary identifiers) in the release pipeline would also address it, and may be the more robust fix since `inherit` is primarily a sandbox-inheritance mechanism. Someone closer to the `block/apple-codesign-action` setup should confirm which is correct here — I've only verified the diagnosis, not the fix.

## Environment

- Buzz Desktop **0.4.24** (Block-signed, `TeamIdentifier=EYF346PHUG`, notarized, `codesign --verify --deep --strict` passes)
- macOS **26.5.2** (Apple Silicon)
- 1Password CLI 2.32.0 (`TeamIdentifier=2BUA8C4S2C`)

## Impact

Any macOS user running managed agents that invoke external tools touching other apps' data. The app is unusable while an agent runs — the dialog steals focus repeatedly and cannot be permanently dismissed, because no grant can ever attach to the app.