test(examples): the GL members pin the glfw that carries the new farm

`compat.glfw` took 3.4.0.1 when its pin on `compat.glx-runtime` moved to
2026.09.11, and nothing moved with it: `imgui-window` and `gui-stack` still
pinned 3.4, so they resolved the old chain and the bump was inert. A version
nobody pins is a version nobody exercises -- these two are the only members that
reach the GL farm at all.

Both build against compat.glx-runtime@2026.09.11. They are libraries rather
than programs, so mcpp's dlopen-surface check does not apply to them and says
so; the farm's own closure is asserted structurally, by reading each member's
DT_NEEDED against the farm alone.

Measured on this host: the farm is 86 members with no unmet soname and no entry
taken directly from /usr/lib -- four route through xim:nvidia-gl-host-link,
twenty-eight through other xim payloads, the rest through the subos view. A
probe that dlopens every member opens all 86; that probe cannot isolate the
farm from the subos, which a control confirmed, so it is evidence that the
members load and not that the farm alone suffices.

Author: Sunrisepeak

tests/examples/gui-stack/mcpp.toml

@@ -7,7 +7,7 @@ name = "gui-stack-tests"
 version = "0.1.0"
 
 [target.'cfg(linux)'.dependencies.compat]
-glfw = "3.4"
+glfw = "3.4.0.1"
 x11 = "1.8.13"
 xcb = "1.17.0"
 xext = "1.3.7"

tests/examples/imgui-window/mcpp.toml

@@ -7,6 +7,6 @@ version = "0.1.0"
 
 [target.'cfg(linux)'.dependencies.compat]
 imgui = "1.92.8"
-glfw = "3.4"
+glfw = "3.4.0.1"
 [target.'cfg(linux)'.build]
 ldflags = ["-ldl"]