fix: fail closed when capture filters are unsafe

[Jah-yee]

Problem

Both capture paths built their self-exclusion list by comparing bundle identifiers. If ScreenCaptureKit had not listed Mac Duo yet, or reported no bundle identifier, that list could be empty and capture would continue. A screenshot could then contain a lingering overlay, while a live stream could feed the overlay back into itself.

Change

• centralize self-exclusion selection for screenshots and live streams
• require the current process ID to appear in SCShareableContent before constructing a filter
• exclude this exact process even when its bundle identifier is missing
• when a bundle identifier is available, also exclude other Mac Duo instances
• clear cached filter identity on every failure
• leave a failed stream start retryable instead of keeping isStarted stuck

This intentionally fails closed: when ScreenCaptureKit cannot prove that the current process is excluded, Mac Duo skips that capture instead of risking recursive or stale overlay content. A transient miss at the trigger boundary can make that lid cycle fall back to a still seed; the next normal cycle retries.

Validation

• debug build with Swift warnings treated as errors
• release build with Swift warnings treated as errors
• universal arm64/x86_64 app build
• git diff --check
• based on current main, retaining the capture-cancellation guards merged in PR Makes the lid effect shut down more cleanly #3
• manually combined with PR fix: apply Live rendering changes during active effects #15, followed by debug and release warnings-as-errors builds

Coordination

PR #15 also changes the asynchronous stream-start and filter-rebuild lifecycle, so the two PRs have a small textual conflict in ScreenStreamer. The tested resolution keeps #15's start-generation checks together with this PR's fail-closed exclusion helper and post-rebuild filter readiness check.