fix(macos): restore CloudKit pull sync and stop CLI SIGABRT on exit

[pseudobun]

Summary

Two related production bugs surfacing as one user-visible problem: the CLI is unusable across machines.

Bug 1: Cross-machine data divergence

The Mac mini and MacBook show completely different sets of tosses despite both being signed in to the same iCloud account, both running the same release, and both pointing at the same `iCloud.lutra-labs.toss` container.

`release.yml:173-177` strips both `aps-environment` and `com.apple.developer.aps-environment` from the macOS app's signed entitlements before codesigning, with a comment claiming "we don't use APNs on macOS." That's wrong on a load-bearing point: `NSPersistentCloudKitContainer` (the engine SwiftData uses for `cloudKitDatabase: .private(...)` mode) needs `aps-environment` to receive CloudKit silent push notifications. Without it the OS never wakes the app for "remote changes happened" pushes, so the local SwiftData store never pulls from CloudKit. Each Mac becomes a write-only island whose store reflects only what that machine itself wrote.

I verified the parent app's embedded provisioning profile (`/Applications/Tossinger.app/Contents/embedded.provisionprofile`) authorizes `aps-environment: production`, so the entitlement can be present — the workflow just deletes it. The fix substitutes the value (development → production) instead of stripping the keys.

Bug 2: CLI SIGABRTs at process exit

`toss ls` consistently crashes after printing results with:

```
NSInternalInconsistencyException 'Invalid parameter not satisfying: bundleIdentifier...'
-[PKUserNotificationsRemoteNotificationServiceConnection initWithBundleIdentifier:]
-[PKPushRegistry _registerForPushType:]
-[NSCloudKitMirroringDelegate dealloc]
-[NSPersistentStore dealloc]
TossKit Container.deinit
ListCommand.run
```

Read bottom-up: the command finishes, prints results, exits → SwiftData tears down → `NSPersistentCloudKitContainer` deallocs → CloudKit cleanup tries to register for push types via `PKPushRegistry` → PushKit looks up the bundle identifier through some path that doesn't work for a sub-bundled `.app` helper invoked via `/opt/homebrew/bin/toss → /Applications/Tossinger.app/Contents/Helpers/toss.app/Contents/MacOS/toss` → `bundleIdentifier` resolves to nil → assertion fails → SIGABRT.

The CLI doesn't actually need CloudKit. It opens the same SQLite store as the main app via the app group, performs a single read or write, and exits. CloudKit sync is the main app's job.

Changes

`.github/workflows/release.yml` (`Prepare sanitized entitlements` step) — replace the two `Delete :aps-environment` PlistBuddy lines with `Set ... production`. Updated the misleading comment to explain why APNs is actually load-bearing for CloudKit silent push.

`Packages/TossKit/Sources/TossKit/Persistence/PersistenceStack.swift` — added a public `CloudKitMode` enum with two cases:

• `.automatic` — wires the store to the private CloudKit database (current behavior)
• `.disabled` — uses `ModelConfiguration.CloudKitDatabase.none`, preventing `NSPersistentCloudKitContainer` from being instantiated at all

`makeContainer` now takes `cloudKit: CloudKitMode = .automatic`, so the app and share extension are bytewise-equivalent at runtime through the default.

`tossinger/Support/TossEnvironment.swift` — passes `cloudKit: .disabled`. Doc comment explains the rationale (CLI doesn't await async push delivery anyway, and instantiating the CloudKit container in a sub-bundled helper SIGABRTs).

Same store file, same data; only the transport layer for the CLI changes.

Test plan

• Build the CLI helper in Xcode after the TossKit + TossEnvironment edits — should compile cleanly
• Run `toss ls` against the existing populated store — results print, process exits cleanly with no SIGABRT and no PushKit assertion in the logs
• Run `toss add "https://example.com"\` and `toss delete ` — same expectation, no crashes
• Run `toss ls` 10× in a row on the macOS box where the crash was reproducible — expect zero crashes
• Build and run the main macOS app — behaves identically to before (default `.automatic` mode → same `.private(...)` configuration)
• Cut a release with this branch and inspect the workflow log for the `Prepare sanitized entitlements` step — the dumped plist (`cat "${SANITIZED}"` already in the step) should now show `aps-environment: production` and `com.apple.developer.aps-environment: production`
• Confirm `codesign --verify --strict --verbose=2` (already in the workflow at line 205) still passes — entitlements remain a subset of what the Developer ID profile authorizes
• Install the new release on both Mac mini and MacBook, add a toss on one, wait ~30s, verify it appears on the other without manual refresh
• Run `toss ls` on both machines after sync settles — they should converge

Notes

• The two open PRs (this one + fix(ci): pin iOS Release to manual signing, stop minting dev certs #16 cert spam) touch different regions of `release.yml` (this one edits ~line 176, fix(ci): pin iOS Release to manual signing, stop minting dev certs #16 edits ~lines 437/450) so they shouldn't conflict whichever order they merge in.
• The share extension stays on the default `.automatic` mode — iOS extensions don't have the CLI's PushKit instantiation problem since they run in the parent app's bundle context. Could be revisited if it ever proves problematic.
• Existing `~/Library/Group Containers/group.lutra-labs.toss/default.store` files (which carry CloudKit sync metadata from prior `.private(...)` use) open cleanly with `.none` — opening a CloudKit-mirrored store from a non-CloudKit context is a supported pattern and a no-op on the metadata side. The next time the app runs with full CloudKit it picks up CLI-written rows via NSPersistentHistoryTracker and pushes them.

🤖 Generated with Claude Code