quest: stats tracks fail loud on an oversized frame

quest/m1/README.md

@@ -119,6 +119,8 @@ explicit exception to the public model audit.
 - [Binding track resolver](/quest/m1/binding-track-helper.md) - binding apps subscribe to a rendition without inlining `track` or the key
 - [Exporters follow a rendition to a new track](/quest/m1/export-rendition-rebind.md) - the fMP4, TS, MKV and FLV exporters rebuild a rendition whose resolved `track` or `broadcast` changes under the same ID
 
+- [Stats fail loud](/quest/m1/stats-frame-too-large.md) - a stats track whose frame outgrows the cache ends with FrameTooLarge instead of serving a stale snapshot
+
 - [C++ and OBS package proof](/quest/m1/cpp-package-check.md) - the installed artifacts pass before their first release
 
 ## Related

quest/m1/stats-frame-too-large.md

@@ -0,0 +1,20 @@
+# [XS] Stats tracks fail loud on an oversized frame
+
+## Goal
+
+A stats track whose next frame exceeds the cache limit ends with
+`FrameTooLarge` instead of silently serving its previous snapshot, so a
+reader learns the track stopped tracking the relay.
+
+## Plan
+
+- `TrackPair::publish` in `rs/moq-stats/src/produce.rs` gets
+  `FrameTooLarge` from `update` (payload over `group::MAX_CACHE_BYTES`) and
+  only logs it at debug level; readers keep the stale frame indefinitely.
+  `publisher.json` near 50k paths is the likely first hit.
+- Abort only the flavor whose `update` failed (log at warn) and keep its
+  sibling publishing: DEFLATE can shrink an oversized plain frame or
+  slightly grow a fitting one. Test that the overflowing flavor ends with
+  `FrameTooLarge` while the other keeps updating. Prefix tracks get the same
+  rule from [Stats prefix tracks](/quest/m2/stats-prefix-tracks.md).
+- Found in #5719.