v2: Ship signed notarized releases with stable macOS permission identity

[jmcte]

Problem / intent

Source-build installation produces no stable signed code identity. For a CLI reading TCC-protected Photos, Reminders, Contacts, Messages, and Safari data, permission continuity across upgrades is a product requirement. The only GitHub release is v0.1.0 with no downloadable assets, while main is materially ahead.

Acceptance criteria

• Produce versioned universal macOS artifacts with checksums.
• Sign with a stable identifier/designated requirement, notarize, and staple the distributed artifact.
• Add a Homebrew installation/upgrade path or document why another signed distribution path is safer.
• Validate first-install authorization and same-path upgrade permission continuity on a clean test account/VM.
• Publish release evidence without secrets or private test data.
• Reconcile CLI/VISION versioning, project.bootstrap.yaml release settings/archetype, missing docs/bootstrap/onboarding.md, and release documentation.
• Decide which GitHub security features should be enabled and record any plan/API blockers.
• Do not introduce a daemon/helper solely to solve signing; coordinate that decision with Decide the provider, helper, and daemon execution model #83.

Dependencies

• Provider permission identities from v2: Define a versioned provider capability manifest #89 should be stable before release validation.
• Productionization follow-up to closed issue Choose package install and release path #5.