Use audio-only system capture and add Meetings plus menu

[r3dbars]

Summary

• Replace the default meeting system-audio backend with Core Audio process taps. New installs request system-audio-only access; no screen-capture fallback.
• Preserve existing users' permission cache and OS grants. Narrowing an old broad grant is optional, with instructions in Settings.
• Treat silent tap buffers as indeterminate, not proof of permission or denial. Nonzero finite PCM verifies capture; no mandatory playback check before every meeting.
• Add a compact plus menu beside search on Meetings: Record a meeting and Transcribe a file…, reusing existing actions and the app's hover styling.

Verification

• Final app build and launch smoke passed; final fast suite: 14,066 assertions passed, 0 failed.
• Full automated QA bench for the audio implementation: 15/15 checks passed (before the subsequent small header UI change). Build/fast suite rerun after final UI changes.
• Focused permission runner: 209 assertions passed. Isolated Core Audio ring/lifecycle suite: 19 tests passed.
• Standalone production-backend probe captured nonzero system audio with only the narrow permission enabled. Disabling permission returned silent buffers; restoring it restored nonzero capture.
• Local integrated meeting displayed both microphone and system-playback speech. Owner tested the local app and accepted the final plus control.
• Native UI inspection verified menu choices and file picker. Screenshot verified final plus-button layout. Full scripted UI smoke not run.
• Independent review against main found a reentrant recovery-after-stop bug, which was fixed and retested. Follow-up menu review found no blockers. Minor existing analytics labels still identify reused actions as empty-state actions.
• Evidence and reproduction: experiments/audio-only-probe/README.md.

Release hold / remaining work

• Resolve and independently review the recording-end tail issue: PCM queued in the new backend ring can be dropped when host writer admission closes at stop. Backend-only draining is insufficient; writer lifetime/admission needs coordinated handling.
• Test a genuinely fresh install and first audio-only prompt using the signed app identity.
• Test an upgrade with only the old broad screen/system-audio grant, without requiring users to manually switch permissions.
• Test integrated app denial, re-enable, and relaunch recovery. Silence alone cannot distinguish denial from a quiet Mac.
• Verify real call playback, AirPods/Bluetooth and output-device changes, sleep/wake, and final retained audio.
• Complete signed/notarized packaging and release/update-path checks before publication.

This PR does not publish a release, replace the installed Applications copy, or change users' OS permissions automatically. Automated checks and single-Mac smoke are not shipping sign-off.

[r3dbars]

Follow-up: report unverified system audio honestly

A supervised denied-permission test showed that retained system-audio files could contain only silence while the recording was reported as fully successful. Microphone audio remained usable.

This update preserves recording and quiet starts, but normalizes a completed recording with explicitly unverified system signal to system_audio_unverified. Saved recordings show an explanation, usage health counts the result as unknown, and support packets no longer label it successful or recovered. Known failures and partial/degraded outcomes retain precedence. Silence alone is not labeled permission denial.

Old metadata caches are invalidated so existing saved verification flags are read. Legacy/imported recordings with no flag are not given the new warning. No new private telemetry fields or permission grants.

Independent review of the complete follow-up patch found no blocking findings. The focused production support-packet suite passed all 117 assertions. Native UI verification confirmed the warning and explanation on the real saved denied-state test recording, including old-cache migration.

Final combined-candidate full QA passed all required automated steps (14 pass, one non-blocking local-artifact warning, zero failures), at commit 368d525b. Only this follow-up fix was cherry-picked onto this PR as 9108f128; the other bug batch was not added to this PR. Standalone branch QA and fresh hosted checks are still running. PR1749 was normally updated with this base, and its eight focused stop-tail/metering tests pass.

This is not a release-readiness claim: a clean post-regrant recording, controlled quiet-start/endings and device routes, a true first-install permission prompt, signed broad-grant upgrade, and receiving-end call audibility still need exact-build evidence. No release or customer notification is included.

[r3dbars]

Quiet-start and onboarding follow-up

Adds the two reviewed follow-up fixes:

• Start the private Core Audio aggregate without waiting for another app to begin playback (kAudioAggregateDeviceTapAutoStartKey = false). Tests inspect the actual production configuration and cover valid silent buffers followed by signal.
• Separate onboarding permission checks from verified audio: show Checking, then Granted only with verified evidence; inconclusive checks show Not yet verified with Check and a direct Settings link. Silence does not fabricate a grant. Onboarding no longer starts competing probes on activation; navigation cancels the owned explicit check.

Evidence and boundaries

• Combined candidate: app build passed; 14,272 fast assertions passed; focused permission suite 287/287; quiet-start Core tests 23/23; independent reviews found no blocking issues.
• Signed local installer and mounted payload signatures/checksums/revision verified. This is an unnotarized local test installer, not a published release.
• Supervised native checks on that combined candidate verified quiet-result presentation, Settings round-trip, cancellation/navigation, actual system audio changing the row to Granted, and Granted surviving restart. Audio-only grant was enabled; no broad screen-recording grant.
• Fresh first-consent behavior, denied-to-enabled recovery on the latest build, old broad-grant upgrade, additional hardware routes and remote participant audibility remain open. Local combined-candidate evidence is not exact-head hosted CI proof for this standalone PR.
• No merge, release, or customer-resolution claim. The companion stop-tail PR is reconciled against this updated base without duplicating its tests here.