fix: preserve window corner radii in preview overlay

[william-laverty]

Change Summary

Fixed the preview overlay rendering with sharp corners (radius 0) when "Prioritize selected window's corner radius" is enabled on macOS 26+. The preview now correctly displays the selected window's actual corner radii, and the "Default corner radius" slider properly serves as a fallback when window radii are unavailable.

Changes

Fixes #1083:

• Removed the inset(by: previewPadding) call from the cornerRadii computed property in PreviewView.swift which was subtracting the padding value (~10px) from the window's actual corner radii (~10px), collapsing them to 0
• The nil-coalescing fallback to the slider value now correctly triggers only when overrideCornerRadii is nil (toggle off, pre-macOS 26, or window radii unavailable), rather than being permanently bypassed by a non-nil but zeroed-out result
• Padding changes no longer inversely affect the visible corner radius — padding controls layout spacing only, as intended
• Removed RectangleCornerRadii+Extensions.swift — the inset(by:minRadius:) extension now has zero callers (the other inset calls in the codebase are SwiftUI's built-in InsettableShape.inset(by:) on RoundedRectangle, not this custom extension)

[MrKai77]

Firstly, please make sure to follow both our issue and PR templates; they both currently don’t adhere to Loop’s emoji conventions, and you are required to disclose any AI usage and how it's been tested :)

Secondly, your issue describes:

1. inset(by: previewPadding) collapses corner radii to 0 — Typical macOS windows have corner radii of ~10px. The default previewPadding is also 10px. The inset(by:) function in RectangleCornerRadii+Extensions.swift computes max(10 - 10, 0) = 0, eliminating the corner radius entirely.
2. The slider fallback never fires — The ?? nil-coalescing only falls back to the "Default corner radius" slider value when overrideCornerRadii is nil. But it's not nil — it's a valid RectangleCornerRadii that has been inset to all zeros. So the slider is completely ignored whenever the window has any non-zero corner radii.

That said, this behavior is intentional. The nil-coalescing should only apply when we fail to retrieve the window’s corner radius via SkyLight. In this case, the retrieval succeeds, and the value is just later reduced to 0 (which is where it looks visually displeasing). I left another comment on the PR, but here’s how I’d approach it:

Since 0pt corner radii are really the only case that looks off, it would make sense to keep the current insetting logic relative to the preview padding, but add an additional check. If the computed override results in a 0pt radius, we should then Loop should fall back to the default corner radius.

Let me know if that doesn’t make sense!

[MrKai77]

The .inset here was intentional. It ensures the preview maintains concentric corner alignment with the main window, as shown:

• Without any preview padding:
  

• With 10 pt preview padding:
  

• With 20 pt preview padding: