Summary

• syncMeetingTool.ts (the meetings MCP tool's manual sync action) and mastra/tools/event-execution/createAndLinkEventsTool.ts's meeting branch both call findOrCreateMeetingEvent directly with a driver's meeting data, but never called storeMeetingInS3 or resolved a connectionId , unlike the webhook (meeting-agent.ts) and initial-sync (meeting-steps.ts) paths, which both do this before the event reaches the DB.
• Net effect: a meeting attached through either of these two paths got a DB row claiming a transcript existed (hasTranscription: true, a real word count) while the S3 blob transcriptionKey should point to was never written , so the UI showed "no transcript available" despite the metadata looking correct. Found and confirmed live against real Gong calls in a customer account (Warp) via both paths.
• Prior art: a closed, unmerged PR (#2662, "Persist meeting transcripts inside findOrCreateMeetingEvent") investigated this exact bug back on 2026-09-02 and identified the same two call sites. It centralized the fix inside findOrCreateMeetingEvent, but Greptile flagged a real flaw: a failed S3 write there still inserted the row with hasTranscription: true, permanently blocking any later retry (the hydration guard only upgrades a row that doesn't already claim a transcript) , so it was never merged. This PR fixes each call site individually instead and deliberately leaves storeMeetingInS3 unguarded (matching meeting-agent.ts's existing pattern) , a failed write aborts event creation entirely rather than inserting a poisoned row, so a retry of the whole operation tries the S3 write fresh.
• Both fixes: resolve the caller's connection row for the matched provider, call the driver's best-effort hydrateTranscript (matching meeting-agent.ts's webhook path), then storeMeetingInS3 before findOrCreateMeetingEvent , same order the other two ingestion paths already use.
• syncMeetingTool.ts also threads the resolved connectionId into its existing Turbopuffer upload call, which previously hardcoded '', and gained a transcriptStored: false output field for the one narrow (traced: TOCTOU-only, not reachable via bad input) case where the connection row can't be found , a thermo-review finding, since that fallback previously returned a fully-successful response with no signal that the transcript wasn't stored.
• createAndLinkEventsTool.ts doesn't need an equivalent field , it already returns the full meetingEvent DB row via meetingEventResult, so transcriptionKey/hasTranscription are already inspectable.
• Handles the no-connection-row edge case defensively (logs loudly, still creates the event without a transcript key) rather than crashing the whole attach in both places.

Test plan

• pnpm --filter @zero/server run types , clean
• pnpm deps:check , no violations (1786 modules, 9356 dependencies)
• pnpm --filter @zero/server exec vitest run src/mastra/tools/meetings/__tests__/ src/mastra/tools/event-execution/__tests__/ , 155/155 passing (17 files)
• 5 new tests in syncMeetingTool.test.ts + 6 new tests in a new createAndLinkEvents-meeting-transcript.test.ts, pinning: S3 write happens before the DB write, an existing transcriptionKey is never overwritten, hydrateTranscript is called and its failure is non-fatal, the event still gets created (without a key) when no connection row is found, and (sync tool only) transcriptStored: false surfaces in that case.
• Fixed the same bare-barrel-mock issue in 4 test files that broke once these tools started importing isProviderId (which transitively needs MEETING_PROVIDER_IDS from the same mocked @/services/integrations/meetings module)
• Ran thermo-review on the initial (sync-tool-only) diff , traced every claim to its callee, verified ordering/error-handling parity with meeting-agent.ts, applied its one finding (the transcriptStored signal)
• Manually backfilled 3 real, already-br