Name the process that has the microphone

[TerrifiedBug]

Fixes the reported bug: a recording that starts by itself gave no option to exclude the app behind it.

What was wrong

The Ignore button on the prompt and on the auto-record banner was gated on having a bundle id, and identity came only from proc_pidpath -> outermost .app. Two common capture clients have neither:

• a system daemon has no .app on its path at all — macOS's speech daemon holds an input stream continuously when "Hey Siri" is on;
• proc_pidpath returns 0 bytes for a process whose binary was replaced under it, which is every self-updating app's helper.

Either one produced a bare "Recording meeting" pill with no name and no Ignore, so there was nothing to click and no way to stop it recurring short of turning detection off.

A second defect made the exclusion list cosmetic even where it did match. A client we had answered about stayed the one the detector followed, and following it is a cache hit that short-circuits the scan — so a process that holds the microphone for hours hid every other app behind it, and no real call could be detected while it ran.

What changed

• MeetingTitle.app(forPID:audioBundleID:) resolves identity from the executable path and falls back to Core Audio's own attribution (kAudioProcessPropertyBundleID, 0.02 ms, read only when prompting). The id is resolved through the installed copy and collapsed onto the outermost .app, so a helper reads as the app that owns it under the id the Settings picker would have stored, and a daemon keeps its raw identifier with its last component for a name. A bare executable stays anonymous — there is genuinely nothing to store.
• MeetingDetector.ignoreCurrentClient() drops an excluded client out of the scan like our own pid, so the scan carries on to whatever else has the microphone. Held by pid, cleared when the microphone goes idle so config edits take effect.
• The daemon passes a MeetingApp? through; the pill and prompt take their name and Ignore label from it.
• README: a paragraph on capture clients that are not apps you launched.
• Stale comment corrected with measurements.

Measured (M4, p50)

step	cost
device gate	0.11 ms
cached client re-check	0.74 ms
full client scan (32 clients)	3.8 ms — the comment claimed ~45 ms
Core Audio bundle id read	0.022 ms

Nothing new runs while idle; the extra read happens only on the poll that prompts.

Verification

Before/after with harnesses compiled from the real sources, against live capture clients, holdA/holdB being bare executables that take the mic:

main:  t=  2.1s  start pid 734 -> nil "nil"          # the reported pill
       (nothing for the next 18 s — three other clients came and went, all hidden)

this:  t=  2.1s  start pid 734   -> com.apple.CoreSpeech "CoreSpeech"   [Ignore CoreSpeech]
       t=  4.1s  start pid 43465 -> com.nousresearch.hermes "Hermes"    [Ignore Hermes]
       t=  6.1s  start pid 65759 -> nil (no identity)                   [Dismiss only]
       t=  8.1s  start pid 65848 -> nil (no identity)                   [Dismiss only]

On the installed build, read out of the accessibility tree and clicked through System Events:

pill:   «Recording CoreSpeech call» «Stop from the menu bar or here»  buttons:[Ignore][Stop]
click:  CoreSpeech added to the ignore list
        stopped · 0:02 · …/2026.09.07-0913
after:  CoreSpeech is excluded — ignoring
        Hermes is excluded — ignoring
        Your microphone is in use          <- a new client still found behind both

That last line is the positive control for the second fix: with two ignored clients on the microphone, a fresh one is still detected, which main cannot do.

Local gate green: swift test, swift build -c release --arch arm64, the three smoke subcommands and the embedded __info_plist check.

Version bumped to 0.3.1 with release notes in CHANGELOG.md.