Navigation safe area subcompose refactor

[dfabulich]

• Fixes SkipUI should use Compose WindowInsets instead of a _safeArea environment value #493

This is currently a draft PR partly because I'm not yet sure there are enough tests, and also because I'm not sure this is the right direction.

• NavigationStack and TabView have inadequate automated testing #492

This PR uses SubcomposeLayout to layout the TopAppBar and the body content of the NavigationStack, mirroring the implementation of Compose Scaffold (see their implementation.)

This eliminates the need to use onGloballyPositioned to measure the app bar, eliminating layout shift.

Skip Pull Request Checklist:

• REQUIRED: I have signed the Contributor Agreement
• REQUIRED: I have tested my change locally with swift test
• OPTIONAL: I have tested my change on an iOS simulator or device
• OPTIONAL: I have tested my change on an Android emulator or device
• REQUIRED: I have checked whether this change requires a corresponding update in the Skip Fuse UI repository (link related PR if applicable)
  (Not required)
• OPTIONAL: I have added an example of any UI changes to the Showcase sample app

---

• AI was used to generate or assist with generating this PR. Please specify below how you used AI to help you, and what steps you have taken to manually verify the changes.

Cursor generated the core of this PR. I manually tested it with the Showcase app in the SafeAreaPlayground, but I'm not confident I've done enough manual testing; I don't want to invest a lot of energy into it unless we agree that this is something like the right approach.

[timkoss]

We have a related production reproduction in OurApp.
The app has a custom, app-owned header above several titleless NavigationStacks—one stack per tab. On Android, each stack reserves a large blank region immediately below the custom header. The same gap appears on every tab. iOS does not show this gap.
The custom header is not a navigation bar, so the stack appears to be applying the system top inset again below content that already accounts for the app header. This seems different from the first-frame navigation-bar measurement jump described in PR #475; our issue is a persistent gap, not only an initial layout flash.
We tried app-level toolbar visibility changes and temporarily tested a local SkipUI change, but we reverted the experiment because it was not a safe application-level fix.
Does this PR intend to address a NavigationStack placed below external, app-owned chrome? If so, would it be useful to add a regression case containing:

• an external fixed-height header
• a titleless NavigationStack below it
• navigation-bar visibility changes
• push/pop navigation
• tab switching
• verification that the body begins immediately below the external header
  We would prefer to follow the upstream direction rather than maintain a permanent SkipUI fork.