quest: plan the follow-ups of #85 and #91

quest/m0/README.md

@@ -102,6 +102,8 @@ repository.
 - [Browser sources on the GPU under Mesa](/quest/m0/cef-headless.md) - shared-texture pages paint on Intel and AMD under Wayland, and a page that cannot paint fails loudly
 - [Browser sources make no outside requests](/quest/m0/browser-offline.md) - no component updates, spellcheck downloads, or network time from the helper
 - [A media file's sound plays with its pictures](/quest/m0/media-av-sync.md) - media sources write a bus latency ahead, as broadcast sources do
+- [Catalogs finish when the studio quits](/quest/m0/catalog-finish.md) - the program's and the recording's catalogs end with `finish()`, not a drop
+- [The UI keeps its frame rate while the program renders](/quest/m0/ui-frame-rate.md) - the editor draws without waiting on the program's render
 - [The Apple signing identity is available](/quest/m0/signing.md) - the Apple credentials packaging and the macOS camera need; Windows ships unsigned
 - [Packaging](/quest/m0/packaging.md) - a signed macOS app, a Windows installer, and a Flatpak for Linux
 - [The persistable portal restore token is pinned](/quest/m0/pin-portal-token.md) - moq-video's restore token, for Wayland sources

quest/m0/catalog-finish.md

@@ -0,0 +1,22 @@
+# [S] Catalogs finish when the studio quits
+
+## Goal
+
+When the studio quits or stops publishing, the program's catalog and the
+recording's catalog end with `finish()`, so a viewer reading either sees a
+clean end, not a cut-off track, and the studio logs no
+`track::Producer dropped without finish() or abort()` warning on quit.
+
+## Plan
+
+From [moq-dev/studio#91](https://github.com/moq-dev/studio/pull/91), picked
+2026-11-07 (maintainer away under /afk, recommended option), m0 by the rule
+that fixes join m0.
+
+On quit the studio logs that warning for `catalog.json` and `catalog`, twice.
+`Program::drop` (`rs/moq-studio/src/engine.rs`) closes the program's broadcast
+without finishing its catalog, and the recording's catalog is dropped the same
+way. First confirm from the viewer's side what a viewer reading the catalog
+sees today, then finish each catalog before its broadcast closes. Tests read
+the program's catalog through a relay and the recording's catalog from the
+local broadcast, quit, and see each one finish.

quest/m0/ui-frame-rate.md

@@ -0,0 +1,27 @@
+# [M] The UI keeps its frame rate while the program renders
+
+## Goal
+
+The studio's UI draws its frames without waiting on the program's render, so
+the editor stays as smooth as the display allows while the studio publishes
+or records.
+
+## Plan
+
+From [moq-dev/studio#85](https://github.com/moq-dev/studio/pull/85), picked
+2026-11-07 (maintainer away under /afk, recommended option), m0 by the rule
+that fixes join m0.
+
+#85 measured the UI at about 25 fps (40 ms a frame) with effects Full,
+Reduced, and Off alike, while the program rendered in about 19 ms, on
+`nixos`'s RTX 3070 Ti under Xvfb at 1440x900. The UI's own CPU work was
+under 2 ms. Its unprofiled guess is that the UI waits on `engine.state`'s
+lock while the program renders.
+
+- Profile first, on a real display as well as Xvfb, since Xvfb's
+  presentation may account for some of it. Report frame time, where the UI
+  thread waits, and GPU queue contention between the UI and the compositor.
+- Fix the cause found, such as holding `engine.state` only to copy what a
+  frame draws, or keeping the compositor's submit off the UI's path. If the
+  wait is only Xvfb's, record that in the PR and delete this quest.
+- Show the program's render time and encoder load are unchanged.