fix(ui): keep flexible children inside their parent, and let weight win

[nicolas-maman]

What

Two reported bugs, plus a third found while confirming the second.

ui.timer stops during modal tracking (#97)

scheduledTimer registers in the default run-loop mode alone, and AppKit runs
slider drags, scrollbar drags, menu tracking and live window resize in
NSEventTrackingRunLoopMode, where a default-mode timer does not fire. An
animation or a clock stopped dead for as long as the mouse was held down and
jumped on release. The timer now goes into the common modes.

Flexible children overflow their parent by the rounding remainder (#101)

The layout was never wrong. Auto Layout divides a 302px row exactly:

96.5 + 6 + 97 + 6 + 96.5 = 302.0

The readback was wrong. It rounded each child's SIZE on its own, so those
three frames reported as 97 / 97 / 96.5 rounded up to 97, a total of 303 in a
302px parent. The report's own numbers show it: x=206 w=97 where the true
frame is 205.5 + 96.5. Positions already rounded consistently, sizes did not.

A reported size is now the distance between two ROUNDED EDGES, so adjacent
children tile: one child's trailing edge is the next one's leading edge, and
the row reads back as 97 + 97 + 96 = 290, plus 12 of gaps, exactly 302. The
remainder is spread rather than dumped on the last child, so the widest and
narrowest differ by at most a pixel, which is the distribution the issue asks
for.

Fixed in get_width / get_height and in the /widgets and /widget/N
geometry the driver reports, on AppKit and on GTK4. GTK4 had the same
independent rounding by truncation, which under-reports rather than overflows,
but breaks tiling the same way. Win32 already derived its sizes from integer
edges and needed no change.

weight() silently overridden on buttons

Confirming the weighted-pane half of #101 turned up a separate bug. A row of
buttons gets an equal-width chain by default, which is what gives the
calculator its grid-like rows. That chain is a required constraint and the
proportional shares from weight() are not, so weights of 16 / 62 / 22 came
out 500 / 500 / 500 in a 1500px row, with no diagnostic. set_width already
retracted the chain for exactly this reason; weight now does too.

Before and after, same program:

weighted=500/500/500   vs row=1500
weighted=240/930/330   vs row=1500

240 / 930 / 330 is 16% / 62% / 22% of 1500, and it sums to the row exactly, so
this also settles the "237 + 918 + 326 = 1481" case in the report.

Verification

• aeb .all.ae builds clean, zero warnings.
• flexround_demo reports buttons=97/97/96 in a 302px row and
  weighted=240/930/330 in a 1500px row. Both sum to their parent exactly.
• Measured the raw fractional frames first, rather than trusting the rounded
  numbers, which is what showed the layout was already correct and moved the
  fix to the readback instead of to the constraints. An earlier attempt that
  lowered the equal-width constraint's priority changed nothing and was
  dropped.
• spec_flexround_demo asserts relationships between the reported numbers,
  not per-backend pixel counts, so it means the same thing on AppKit and
  GTK4. Wired into ci.sh phase 5k6. Driver specs cannot run in the local
  sandbox, which blocks the bind, so CI is what exercises it; the spec itself
  compiles clean against the driver library.
• No existing spec asserts an exact widget width, so nothing depends on the
  old numbers.

Closes #97
Closes #101

🤖 Generated with Claude Code