Decide the provider, helper, and daemon execution model

[pheidon]

Problem / intent

icloud-cli is currently a local, read-only, on-demand CLI and VISION.md names daemon behavior as a non-goal. Its growing set of TCC-protected providers raises a legitimate design question: should one process own every permission, should stable per-domain helpers isolate permission blast radius, or should the CLI delegate to mature tools such as imsgcrawl and remindctl?

This issue is an architecture decision, not permission to add a daemon.

Acceptance criteria

• Add an ADR comparing:
  • one on-demand CLI process;
  • a launchd-managed local daemon;
  • stable signed per-domain helpers;
  • delegation to external provider CLIs.
• Compare lifecycle, local IPC/authentication, TCC identity and upgrade continuity, permission blast radius, failure isolation, resource usage, archive ownership, signing/notarization, and operator recovery.
• Classify every provider as public Apple framework, filesystem/plist, private-store fallback, delegated integration, or unsupported, using v2: Define a versioned provider capability manifest #89 as the machine-readable source where possible.
• Decide whether daemon mode remains a non-goal, becomes an optional control-plane feature, or is required for a narrow provider.
• Keep local-only and read-only defaults; any future mutation/action process needs a separate issue and permission boundary.
• Update VISION.md and provider/release documentation with the decision.
• Do not implement a daemon or helper in this issue.

Validation

git diff --check
bash scripts/ci/run-fast-checks.sh

Dependencies

• Provider contract: v2: Define a versioned provider capability manifest #89.
• Stable distribution/TCC validation: v2: Ship signed notarized releases with stable macOS permission identity #98.

Related

• Informed by correctness work in Fail closed on ambiguous MobileMe plist matches #81 and Surface handoff parse failures instead of silent empties #82.