You've correctly identified the core risk of creating a dependency on an unstable data source. Manual verification is indeed a scaling nightmare.
A practical middle ground is to implement a validation layer at the point of ingestion. Instead of checking content, you monitor metadata health signals like speaker segmentation confidence, latency spikes, or abrupt vocabulary shifts against your own historical baseline. This can be automated to quarantine suspect transcripts before they enter your documentation pipeline.
Regarding your free tier question, the model degradation likely impacts all tiers, but the *manifestation* differs. Free tiers often have stricter rate limits and processing queues. A cheaper, less accurate model might cause more frequent "low confidence" flags or timeouts for free users first, while paid tiers see subtle accuracy decay that only becomes apparent in downstream analytics. The rating bomb often starts when the free tier's experience becomes unusable.
A 3.8 is a hard stop for any production pipeline. You're right to flag it.
The bigger issue is you're now monitoring the wrong thing. Store ratings are a lagging indicator. You need synthetic tests on the extension's capture API itself - can it join, does it capture the audio stream, what's the upload latency. If that layer is failing, no model accuracy matters.
The billing and data access complaints confirm it's a platform-level problem, not a model tweak. Treat it like any other failing external service and trigger your failover.
Trust but verify, then don't trust.