Suppress window-level safe-area on outer snapshot VC stack

[dfed]

Why

The existing safe-area pin on ExpandingViewController.view (PR #5) prevents layout-margin-driven safe-area propagation inside the SwiftUI host. But UIKit-based view controllers placed inside a SwiftUI #Preview are wrapped by SwiftUI's UIViewControllerRepresentable bridge, which propagates window-level safeAreaInsets down the parent-VC chain — independent of the host's directionalLayoutMargins.

On the apple-side consumer this surfaces as ~8px run-to-run vertical translation in UIKit-based previews. Two known cases:

• PlanetEditorFlowViewController (delta on intrinsicContentSize: 2064 vs 2072 — exactly 8px, with every row from 322 onward shifted down 8px in the taller render)
• PhotoUploadViewController/Viewfinder (~150px run-to-run translation in earlier drift investigations)

The 8px figure aligns with HeaderLayoutUtility.rects(for:) reading view.safeAreaInsets.top + Metrics.edgeInsets.top (edgeInsets.top = 8). Whether safeAreaInsets lands before or after the settle loop's intrinsic-content-size measurement determines whether the back button (and downstream content) draws 8px lower.

What

Sources/SnapshotPreviewsCore/View+Snapshot.swift:

1. The 3-level VC stack built in setupRootVC (windowRootVC -> containerVC -> subVC) now uses a custom SafeAreaSuppressingViewController for the outer two VCs. Its viewSafeAreaInsetsDidChange override sets additionalSafeAreaInsets to the negation of the window's safeAreaInsets. UIKit clamps the resolved value to >= 0, so the effective inset for that VC and all descendants becomes exactly zero.
2. The outer two VCs also receive the same insetsLayoutMarginsFromSafeArea = false / directionalLayoutMargins = .zero pin already applied to subVC (the ExpandingViewController).

Together this closes both the layout-margin path (already covered for the host) and the parent-VC safeAreaInsets path (newly covered) for UIKit-based previews.

Test plan

The fork-side change is byte-deterministic by construction: zeroing safe-area before measurement removes a source of nondeterministic translation. Verification happens on the apple-side adoption PR — a one-time regen of PlanetEditorFlowViewController/Default/snapshot.png and possibly PhotoUploadViewController/Viewfinder/* is the expected positive signal that the fix landed; subsequent CI runs should not regen those files.

---

Note

Medium Risk
Changes how safe-area insets are propagated for all snapshot previews by altering the root view-controller stack, which can shift layout in rendered images. Risk is limited to snapshot rendering behavior and should surface quickly via snapshot diffs.

Overview
Reduces flaky layout shifts in SwiftUI #Preview snapshots by suppressing window-derived safeAreaInsets in the outer view-controller stack created by setupRootVC.

The root and container controllers are replaced with a new SafeAreaSuppressingViewController that negates window.safeAreaInsets via additionalSafeAreaInsets, and both outer views now also pin insetsLayoutMarginsFromSafeArea = false and directionalLayoutMargins = .zero.

^{Reviewed by Cursor Bugbot for commit dd7e26e. Bugbot is set up for automated code reviews on this repo. Configure here.}

[dfed]

Closing — apple-side adoption (portolans/apple#6042) showed this approach is too aggressive. Zeroing window.safeAreaInsets via additionalSafeAreaInsets affects every view that reads safe-area for .padding/.ignoresSafeArea, producing 210 baseline regens and an outright test failure. The original PR-#5 layoutMargin pin was correctly scoped; window-level safe-area suppression isn't. Will re-diagnose the underlying issue.