feat(platform): let apps offset the window-control cluster - #312

A titlebar style fixes both the band's height and where the system
centres the window controls in it. An app whose own header is a
different height than any offered band therefore cannot line its content
up with them — the only lever was picking a different band, which
changes the window's whole shape (on macOS 26 the tall band also rounds
the window corner harder).
`WindowOptions.window_controls_offset` decouples the two: keep the band
you want and put the controls on your own centreline. Declared in
app.zon as `.window_controls_offset_x` / `_y`, positive right and down,
zero (the default) leaving the platform's placement untouched.
macOS moves the three `standardWindowButton` views; every other platform
ignores it, the same honest no-op `WindowChrome.insets` already reports
on the edge a platform does not use.
The offset is REMEMBERED rather than applied once. AppKit relays those
views out on its own schedule — entering and leaving fullscreen — so the
host stores it and re-applies after each, and each apply sets an
absolute origin from a captured base rather than nudging what is there,
so repeated applies cannot walk the buttons across the titlebar.
Nothing to add for reporting: `chromeInsetsForWindowId:` already derives
`WindowChrome.buttons` by unioning the real button frames, so an app
centring against the cluster sees the moved position with no second
source of truth.

The conversion to WindowOptions dropped the field, so imperatively
created windows always got the default (0, 0) offset. The null platform
now captures the offset at create, and a test covers both a window that
declares one and a window that does not.