feat(sokol+imgui): wire sokol-imgui bridge through gui.labelle

[apotema]

Summary

Adds the assembler-side plumbing for GUI plugins that need sokol_imgui. Until now there was no way for a labelle-imgui-style GUI plugin to make sokol_imgui work, because sokol_imgui is part of sokol_clib (gated by with_sokol_imgui = true at the sokol-zig dep declaration), and the backend's build.zig hardcoded with_sokol_imgui = false. The bridge artifact itself can be tiny — it just needs a way to ask the backend to build sokol with imgui support.

What changes

• backends/sokol/build.zig learns a -Dwith_sokol_imgui build option. When true it forwards to sokol-zig and lazily fetches cimgui (matching hash with labelle-imgui's pin) just to expose its include path to sokol_clib so sokol_imgui.h's IMPL section can resolve cimgui types. The cimgui artifact itself is provided by the GUI plugin and linked at the final exe step — there is only ever one cimgui_clib in the binary.
• gui.labelle bridges learn a needs_sokol_imgui: bool = false field (parsed in gui_resolve.zig, propagated to ResolvedGui in config.zig). The flag is the contract by which a GUI plugin tells the assembler "I want with_sokol_imgui = true on the backend dep".
• build_files.zig checks resolved_gui.needs_sokol_imgui when emitting the sokol backend dep and renders a new backend_sokol_imgui template section that passes .with_sokol_imgui = true. The non-imgui path is unchanged.
• gui_resolve.zig parses gui.labelle with .ignore_unknown_fields = true. This is forward-compat insurance: every new bridge hint flag added here would otherwise require a lockstep CLI bump, since the CLI's pinned generator parses the same manifest.

Companion PR

The C wrapper that re-exports imgui_bridge_setup/begin/end/shutdown against simgui_* lives in labelle-imgui — see labelle-toolkit/labelle-imgui#3.

Architecture note

There is exactly one sokol_clib in the final exe. The bridge artifact does not declare its own sokol — it only needs sokol's header path at compile time (for simgui_desc_t and friends), and at the final link step simgui_* symbols resolve from the backend's sokol_clib. This avoids the duplicate-state problem that would happen if the GUI plugin shipped its own sokol artifact.

Test plan

• zig build - backend compiles with and without -Dwith_sokol_imgui
• Downstream: flying-platform-labelle (sokol backend + imgui GUI via labelle-imgui bridge) builds clean and runs end-to-end
• CI: verify lazy cimgui dep is not fetched when -Dwith_sokol_imgui is unset

[gemini-code-assist]

Code Review

This pull request introduces support for sokol-imgui by adding a with_sokol_imgui build option to the Sokol backend, which lazily fetches cimgui headers when enabled. The project configuration and GUI resolution logic have been updated to propagate the needs_sokol_imgui flag from GUI manifests. However, the current implementation in src/build_files.zig only applies the ImGui-enabled template for desktop platforms; targeting WASM, iOS, or Android with a GUI requiring Sokol ImGui will likely result in link errors as those platform-specific sections do not yet pass the necessary build flag.

[gemini-code-assist]

The ImGui support for the Sokol backend is currently only implemented for the desktop platform. The logic in the switch (cfg.backend) block prioritizes platform-specific checks (wasm, ios, android) and uses their respective template sections (e.g., backend_sokol_wasm), which do not pass the .with_sokol_imgui = true flag to the backend dependency.

As a result, if a user targets WASM or mobile with a GUI that requires Sokol ImGui, the build will likely fail at the link stage due to missing symbols. Consider adding ImGui-enabled variants for these platform templates or refactoring the template sections to accept the with_sokol_imgui flag as a parameter via renderSection.

[cursor]

PR Summary

Medium Risk
Moderate risk because it changes generated build logic and dependency resolution for the sokol backend (including a new lazy external dep), which could affect cross-platform builds if mis-propagated.

Overview
GUI plugins can now request that the sokol backend be built with sokol_imgui support by setting needs_sokol_imgui in their gui.labelle bridge definition.

This wires a new -Dwith_sokol_imgui option through the sokol backend build (including a lazily-fetched, pinned cimgui include path), extends manifest parsing to ignore unknown fields for forward compatibility, and updates the build.zig generator/templates to select platform-specific backend_sokol_*_imgui sections that pass .with_sokol_imgui = true when required.

^{Reviewed by Cursor Bugbot for commit dd2327d. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 00583b9. Configure here.}

[apotema]

Fixed in dd2327d. The sokol arm of the backend dispatch in build_files.zig is now a single nested switch over platform × want_imgui, and there are three new template sections (backend_sokol_wasm_imgui, backend_sokol_ios_imgui, backend_sokol_android_imgui) that mirror the existing platform-specific sections but pass .with_sokol_imgui = true on the dep. Each one keeps the platform-specific knobs (dont_link_system_libs, NDK include paths, SDK paths) intact.

[apotema]

Closing this in favor of the labelle-imgui sokol bridge approach that's now in main (labelle-toolkit/labelle-imgui PRs #1 and #2, merged externally during today's work). Their bridge owns its own `sokol-with-imgui` dep at the bridge level rather than threading a build option through the backend, and #38 + #39 in this repo verified the end-to-end path works without needing the `needs_sokol_imgui` flag this PR added.

The one piece of this PR that's arguably still useful — `ignore_unknown_fields = true` on the gui.labelle parser, for forward compat — could be split into a 3-line standalone PR if we hit a real case where it matters. Not worth keeping this PR open just for that.