Fix hidden overlay chrome intercepting new selection drags

[chablino]

Summary

This fixes an intermittent issue where starting a new screenshot selection could fail when the drag began over the previous position of hidden overlay chrome, such as the tool options row.

The overlay reuses toolbar/options views between capture sessions. In some cases, super.hitTest(_:) could still resolve a mouse-down to a hidden or inactive chrome subview, preventing OverlayView.mouseDown(with:) from starting the selection.

This change keeps visible toolbar/options behavior unchanged, but ignores hidden or inactive overlay chrome hits and routes those mouse events back to OverlayView.

Test Plan

• Built successfully with:
  xcodebuild -project macshot.xcodeproj -scheme macshot -configuration Debug -derivedDataPath / private/tmp/macshot-derived-data CODE_SIGNING_ALLOWED=NO build
• Manually tested repeated screenshot sessions through the previously affected narrow region; selection starts normally instead of being swallowed by the hidden options row.

Demo

Before

before.mp4

After

after.mp4

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Updates OverlayView hit-testing so clicks on inactive/hidden chrome (toolbars/strips/options row) are ignored and routed back to the overlay instead of the chrome subviews.

Changes:

• Overrides hitTest(_:) to post-process the result and return self for inactive chrome hits.
• Adds helper methods to detect whether the hit view is within chrome and whether any ancestors are hidden.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.