Document the Frame's broken Qt WebEngine and the bundling experiment

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/PROGRESS.md

@@ -80,6 +80,18 @@ Known limitation: the bundled-Qt package does not support WebEngine in this iter
   present (relevant for Q2/Q3).
 - libmosquitto ABI check: Debian's 2.0.21 needs at most `OPENSSL_3.0.0`/`GLIBC_2.34`; the
   Frame has OpenSSL 3.2.1 and glibc 2.39. No libcjson dependency. D14 holds.
+- Phase 4 (testing on the Frame), first findings:
+  - `deploy-to-frame.sh` exited silently without a bundled package in `dist/` (fixed).
+  - The system-Qt package doesn't start: the Frame's Qt WebEngine is 6.7.0 (rest of Qt 6.8.0)
+    and built against FFmpeg 6, which the Frame lacks (STEAM-FRAME.md). DSH-1's out-of-the-box
+    variant therefore fails on the Frame; and since the app links WebEngine, the whole app
+    fails.
+  - At the user's request, experiment B: the bundled package now ships Qt WebEngine (Debian
+    6.8.2, own FFmpeg inside) with its helper process and resources: 141 MB archive, 352 MB
+    unpacked. Needs `GLIBC_2.38` and `GLIBCXX_3.4.32` from the Frame. Test pending.
+  - Other options noted: load WebEngine only at runtime so the app survives without it; a
+    native dashboard (DSH-2, Q2b). Qt WebView is no alternative (on Linux its backend is
+    WebEngine; native views are separate windows, not rendered into the texture).
 - Phase 3 of implementation iteration 1:
   - Platform: `prepare()` hook and app-specific command-line options, tested in
     `tst_surfaces` (incl. `surfaces_prepare_fail`).