Report the content size in the macOS window frame event

[sepehr-safari]

The bug

The runtime lays its shell views out into the width and height of the window
frame it is told about:

// src/runtime/window_storage.zig
pub fn shellBoundsForWindow(self: *const Runtime, window_id: platform.WindowId) geometry.RectF {
    const frame_value = self.windows[index].info.frame;
    const bounds = geometry.RectF.init(0, 0, frame_value.width, frame_value.height);

Windows are also created and restored through initWithContentRect:, so on every
other path those two numbers are a content size. The AppKit host reported
window.frame, which includes the chrome.

With a standard titlebar that is 32 points of disagreement.

What it looks like from an app

An app whose manifest asks for 760x760 gets a 760x760 content view, and is then
told its shell is 760x792. It lays out 32 points taller than the view it lives
in, so anything on the bottom edge is placed below the window.

Measured on a real app with a status bar on the floor of its canvas, five
launches out of five:

	canvas the app is told	status bar
before	760x792	y 761 to 792, entirely outside the 760pt content view
after	760x760	y 729 to 760, on the floor of it

CGWindowListCopyWindowInfo reports the window frame as 760x792 in both, so the
window itself was always the right size. Only the number the app was handed
changed.

It reads as intermittent, which is what made it confusing. The bar is absent from
every launch and then appears permanently the first time the window is resized,
because emitResizeForWindowId already sends contentView.bounds and is
correct. Whether anyone sees the bug depends only on whether they happened to
drag the window.

The fix

emitWindowFrameForWindowId reports contentRectForFrameRect: for the size. The
origin stays the frame's, which is what positions the window on screen and what
the restore path already round-trips.

What I tried first, and why it is not this

Making shellBoundsForWindow use self.surface.size instead. The surface does
carry the correct content size, but it is not populated until the host sends its
first resize, so at startup it is still the 640x360 default. That fails

test "runtime lays out startup shell windows with native configured bounds"
  expected 1200, found 640

which is the suite catching it exactly. The host is the right place: it is the
only layer that knows the chrome height, and every other window path there
already speaks in content rects.

Checks

zig build test on macOS produces the same result with this patch as without it.

[vercel]

@sepehr-safari is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.