Fixes a macOS 27 beta regression where clicks on custom titlebar
controls were delayed by the system double-click interval.

After updating to macOS 27 dev beta, I noticed that our titlebar buttons
had a delay before click events took effect. After some digging, I
discovered that AppKit can treat that titlebar region as system-owned
and delay click delivery while waiting to disambiguate double-clicks. I
noticed that Slack had titlebar buttons that weren't affected by the
double-click disambiguation delay, so I had Claude dig through the
Chromium/Electron codebase to discover what they did differently.

Chromium uses a private AppKit SPI,
`_opaqueRectForWindowMoveWhenInTitlebar`, that allows them to set what
regions should be treated as owned by a view vs. owned by AppKit. My fix
uses the same API and returns the view bounds when
`NSWindowStyleMask::NSFullSizeContentViewWindowMask` is set, which
happens when a GPUI app uses a full-size content view for a custom
titlebar. Otherwise, we return bounds of `NSRect::new(NSPoint::new(0.,
0.), NSSize::new(0., 0.))` so apps using macOS's native titlebar still
work as expected.

### Before


https://github.com/user-attachments/assets/ba9e0d2d-b85c-4d98-bc7d-bea00368d9cf

### After 


https://github.com/user-attachments/assets/b78bd7d4-6b43-48d3-a615-2c7a29e32e71


Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

Release Notes:

-  Fixed clicks on titlebar controls being delayed on the macOS 27 beta.