wasm-gui: Root-1 arity MEASURED — quick win already captured at @64; pivot to multi-app levers

Measured @64/@28/@26 (re-fpcast from saved prefpcast, no relink): css-bench CSS parse 894->681ms (24%, dense
GObject), but gtk-hello REAL-APP construction only 3734->3635ms (2.6% -- a simple app is one-time-font/theme bound,
not arity bound). Both render-correct, smaller binary. The arity quick win was already banked @128->@64 (3.7x);
@64->@28 is marginal + overrides a deliberate 2.5x safety margin (measured max 25) -> keeping the @64 default.
Root-1 arity = done; remaining Root-1 lever = per-signature marshallers (days). MEASUREMENT-DRIVEN PIVOT: single-app
construction (~3.7s, tuned) is not the multi-app bottleneck; Root-2 serialization is. Next: #2 in-place pwrite
(framebuffer throughput, cuts service-thread load) then Root-2 multiplex. Numbers in M8-STATUS-LOG T70.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: NathanFlurry

experiments/wasm-gui/M8-STATUS-LOG.md

@@ -283,3 +283,4 @@
 2026-06-26T67b (panel regression-verify PASSED): full xfce4-panel rebuild with the shared gmodule-shim.c additive change -> fresh 54MB binary, exit 0, 0 undefined symbols, 0 thunar refs leaking into the panel link. The consolidation is fully verified: thunar-sbr renamers load via the shared shim AND the panel is unaffected. gmodule chapter closed.
 2026-06-26T68 (thunar-sbr renamers FUNCTIONAL, not just rendered): XTEST-injected "RENAMED_" into the bulk-rename Text field (button 1 + focus + type, POST_INJECT_DELAY 40s, proven --timeout 120) -> the New Name column LIVE-PREVIEWS RENAMED_vacation-001.jpg / RENAMED_vacation-002.jpg / RENAMED_notes.txt and the Apply button enables. Proof: ~/tmp/gui-progress/2026-06-26T17/xu5-thunar-sbr-functional.png. So the gmodule-loaded thunar-sbr plugin RUNS its rename logic, not just draws the dialog -- a functional capstone to the gmodule consolidation (T65-67). (FB-capture note: the first attempt at --timeout 175 emptied the FB; the proven --timeout 120 captured it -- a harness timing detail, not a guest issue.)
 2026-06-26T69 (PERF PIVOT — Root-1 course-corrected by feasibility research): the user-named "typed-function-references" is the WRONG fix for the ~13.4s GObject cascade. A deep research agent (read toolchain+V8) proved call_ref type-checks exactly like call_indirect (the GObject cast mismatch still traps), so typed-func-refs/GC do NOT remove the cost — the cost is binaryen fpcast-emu's UNIFORM max-arity padding + per-call trampoline. V8-here runs GC-wasm fine (V8 130 default-on), so not blocked, just the wrong layer. CORRECTION: no max-func-params@128 exists in-repo; link-xapp.sh:24 uses BARE --fpcast-emu (binaryen default arity). REAL FIX cheapest-first: (1) QUICK WIN hours/one-line — --pass-arg=max-func-params@<measured-true-max> (padding scales with arity; GObject closures 1-4 ptr args); (2) days — force per-signature C marshallers to kill g_cclosure_marshal_generic, then drop/scope --fpcast-emu; (3) weeks — per-arity trampoline tables. Captured in PERF-FINDINGS.md. Also (concrete win #2 in-place pwrite): the analysis caveat is REAL — RootFileSystem uses the DEFAULT VirtualFileSystem::pwrite (vfs.rs:335, read_file full-clone + write_file) via self.overlay (root_fs.rs:307/323); a MemoryFileSystem-only override would be dead — the fix needs pwrite forwarding down the dispatch chain (RootFileSystem→overlay→inner) + an in-place inner impl.
+2026-06-26T70 (Root-1 arity MEASURED — quick win already captured at @64; not over-tuning): re-fpcast css-bench + gtk-hello @64/@28/@26 from saved prefpcast (no relink), ran each via render-app.sh. css-bench CSS parse (4000 rules, pathologically GObject-dense): @64=894ms -> @28=681ms (24%). gtk-hello REAL-APP construction (after gtk_init -> "widget tree shown"): @64=3734ms -> @28=3635ms (ONLY 2.6% -- a tiny app is dominated by one-time font/theme init, not per-widget arity). Binary 14.0->13.5MB; both @28+@26 render-correct (60% nonblack, no trap). CONCLUSION: the arity QUICK WIN was already banked at @128->@64 (=3.7x, 15.3s->4.1s, pre-existing). The remaining @64->@28 is marginal for real construction AND overrides a deliberate 2.5x safety margin (measured max 25) -> NOT changing the @64 default; the SECURE_EXEC_FPCAST_MAXP knob remains for per-build tuning. Root-1 arity tuning = effectively done; the remaining Root-1 lever is per-signature marshallers (structural, days). PIVOT (measurement-driven): single-app construction (~3.7s, tuned) is NOT the multi-app-desktop bottleneck -- Root-2 (single service-thread serialization) is. NEXT: autonomous framebuffer-throughput win (#2 in-place pwrite, cuts per-guest service-thread load) then Root-2 multiplex.