fix(ui): app_quit, resize callback ABI, and panel sizing

[nicolas-maman]

Three reported bugs, each verified by measurement rather than assertion.

Closes #93
Closes #94
Closes #95

#93 — an application could not quit itself

window_close indexed extra_windows directly, so handle 1 meant the first extra window and the primary one had no handle at all, while window_count, window_title and window_is_open all treat 1 as the primary. Nothing else in the surface stopped the run loop.

The cost is the one the report names: a bounded run had to be killed from outside, so timeout 60 ./app always exited 124 and could not distinguish finished its work from hung. A CI step that renders N frames, writes its evidence and should exit 0 reported failure on success.

ui.app_quit() stops the loop on all three backends:

• AppKit: -stop: plus a posted event, because -stop: is only examined when the loop next comes round.
• GTK4: g_application_quit on an idle source, since it must not be called from an arbitrary thread.
• win32: WM_QUIT posted to the loop's own thread, since PostQuitMessage only affects the calling thread.

aether_ui_park_until_killed — what a headless or tray-only app parks on — polls the same shared flag instead of sleeping a minute at a time. window_close(1) now addresses the primary window, consistent with the rest of the family.

Verified: the demo prints its work, returns from the run loop, and exits 0.

#94 — canvas_on_resize passed ints while its four siblings pass doubles

on_click, on_move, on_release and on_scroll all hand their closure two doubles. on_resize handed it two intptr_t, so a closure written the way the siblings are written read the floating-point argument registers while the caller had filled the integer ones. It compiled, ran, and delivered garbage with no diagnostic from the compiler or the runtime — in a 3D viewport sizing its render target from those values, the viewport silently never resized.

Now doubles on all three backends. vg/live.ae, the one in-tree caller, takes floats to match.

#95 — split_set_position ignored on a nested splitview, and no way to state a width

The implementation looked right, and it was: -setPosition:ofDividerAtIndex: does move the divider, and then the next layout pass re-derives the pane's width from its content and puts it back. An inner split appeared to work only because its pane had nothing to derive from.

Pinning the first pane's size is what actually holds. On the reported shape, a 1480-wide window with a populated left panel, asking for 240:

without the fix: left panel width = 1368
with the fix:    left panel width = 240

The second half of the report was that nothing could give a widget a width or ask what width it had, so with the divider unavailable there was no other lever. set_width / set_height / get_width / get_height now exist on all three backends: a real constraint on AppKit (the only thing that survives a layout pass), a size request with expand off on GTK4, the preferred size the layout pass reads on win32. The getters answer from the allocation, so they report what a widget actually got rather than what was asked for.

Coverage

Three new ci.sh phases. 5e20 asserts through the driver that the resize closure receives real values; 5e21 asserts quit_demo exits 0 with its loop returned; 5e22 builds the reported three-panel shape and asserts the left panel measures 240 through get_width.

5e21 and 5e22 deliberately need no driver — the app ends itself and reads its own allocation back — which is what let me verify #93 and #95 locally. The sandbox here currently blocks socket binds (the pre-existing canvasclip_demo fails to serve too), so #94's driver spec is verified by CI rather than on this machine.

🤖 Generated with Claude Code