HUD: switching to the vertical layout and back moves the bar up the screen #951

What happens

Switching the recording bar to the vertical layout and back moves it up the screen. On Windows 11 at 125 % scaling (2.0.0-rc.1, same code on main), each vertical→horizontal round trip left the bar about 130 DIP (162 px) higher than where it started. It repeats on every round trip, so a few toggles walk the bar toward the top of the screen.

Measured with the window bounds (DIP):

The window keeps its top-left instead of re-anchoring on the bar's bottom-centre, which is what hudResizeBounds is written to do.

Cause

Logged the two HUD IPC channels in the main process during the flip:

set-size  648×826  content [297,229,54,577]   bounds before [316,149,908,697]
content            [427,99,54,577]            bounds before [446,19,649,827]   <- stale

Right after hud-overlay-set-size, the renderer's ResizeObserver fires measureHudSize again. It reports the stack rect through hud-overlay-content, measured in the old viewport: [427,99] is the vertical bar centred in the 908×697 window. By then the main process has already resized the window to 649×827, and it stores that rect as hudContentRect. The next set-size anchors on it, and the result is exactly the bounds above.

The stack is always centred and pinned HUD_BAR_BOTTOM above the window's bottom edge (the comment on grantedContent already says so). So its rect can be computed from the allocated size, like grantedContent is, instead of being measured a frame too early.

Fix

In LaunchWindow.tsx, build the reported content rect from the allocated window size, with the same formula as grantedContent. Only its size comes from the measurement.