op CLI desktop-app integration fails under macOS TCC Group Container protection

Environment: macOS (Sequoia/Tahoe), 1Password 8 desktop + CLI 2.35. Integration enabled (Settings → Developer → Integrate with CLI; system-auth unlock on).

Symptom: op reports "No accounts configured." op --debug shows the real cause:
Skipped loading desktop app settings file. The desktop app might not be installed:
open ~/Library/Group Containers/2BUA8C4S2C.com.1password/.../settings/settings.json: operation not permitted

Root cause: op's desktop-app discovery reads settings.json inside 1Password's Group Container. On modern macOS, a process reading another app's Group Container requires Full Disk Access — there's no per-file or per-container TCC grant.

Why the usual workaround is self-defeating: the common "fix" is to add the terminal (Terminal/iTerm) to Full Disk Access. But FDA is machine-wide — it grants that terminal, and every process it ever spawns, read access to all protected app data (Messages, Mail, Safari history, every app's container), not just 1Password's. So to unlock a narrow, biometric-gated secret channel, you're forced to open blanket access to the entire machine's data — a far larger exposure than the credential handling the integration is meant to make safer. It negates the security rationale for using the CLI integration at all, and it's a non-starter on any security-conscious setup.

Note: the actual comms are XPC (op-cli/desktopapp/ipc/xpc), which is not filesystem-TCC-gated — only the file-based discovery is blocked.

Requested fix: move integration discovery to XPC (query a well-known Mach service for "enabled? accounts? policy?") instead of reading a file in the protected container — or write the discovery manifest outside the Group Container. Either removes the FDA requirement entirely, keeping credential access properly scoped instead of forcing a machine-wide grant.