Process meetings with external participants, filter notifications

[suiyangqiu]

📝 Summary of Changes

Corresponding issue: #73

• Tiger no longer skips meetings that have external (client) participants - it now generates the dashboard and saves the transcript for these meetings just like any other.
• External participants are excluded from the Teams notification recipient list across all three notification paths (success, failure, and subject-filter-skip), so they never receive a message from Tiger.

Closes #73

🤷‍♂️ Why

Tiger was silently skipping processing for any meeting with an external participant, which meant no dashboard got generated for spec reviews or other client meetings. As discussed in Sprint 6 Review, it's fine for Tiger to run on these meetings as long as external people never receive the notification - SSW staff can then choose to share the dashboard link manually.

🧪 Test plan

• npm test passes (76/76), including four new tests covering: a meeting with an external participant is not skipped, the external participant is excluded from the success-path notification list, the same for the failure-path notification, and the same for the subject-filter-skip notification path
• Human review of the removed skip-gate functions and the notification-filtering behavior in a real Teams meeting

🦅 Hunted by Vulture · 🤖 Generated with Claude Code

[suiyangqiu]

🦅 Vulture kill summary

2 review rounds. Round 1 found a real Blocking gap (both Doomsayer and the independent reviewer independently traced it): removing the two external skip-gates made a third output path in downloadTranscript.js - the subject-filter "skipped" branch - newly reachable for external meetings, and it was still shipping an unfiltered participant list toward the notification pipeline. Fixed by extracting a shared filterNotifiableParticipants() helper applied at all three outputResult() call sites (success, error, and subject-filter-skip), with new tests covering the error path and the subject-filter-skip path (test count 74 -> 76).

Also actioned: removed unused test-runner imports, and fixed a real bug in the test harness itself (a mocked process.exit() wasn't halting execution, so an early-exit test could fall through into later code and get its result silently overwritten - now "first exit/output wins", matching real process semantics).

One finding was carried forward and declined as a defect rather than fixed: the reused isExternalPerson() heuristic changing failure mode from a loud whole-meeting skip to a silent per-recipient notification exclusion. Both reviewers agreed this is the intended shape of issue #73's own acceptance criteria (process the meeting, only filter the notification), not a regression in the filtering mechanism. Its one legitimate side effect - the old code's exclusion logging being lost - was fixed with a log line.

Round 2 came back green across all three reviewers (Doomsayer verified the fix by reverting it locally and confirming the new test fails without it). Remaining Optional notes for the human reviewer: the export-and-monkeypatch test pattern is workable but could get fragile if the suite grows; a pre-existing, unrelated bug was spotted in fetchMeeting()/extractInviteeNames() (worth its own issue, not touched here); and whether external attendees' own performance commentary belongs on a dashboard that gets manually shared to them is a product question, not a code defect.