✨ Render stock SwiftUI previews with Vizzly

[Robdel12]

Why

SwiftUI teams already describe important UI states with stock #Preview declarations. Vizzly should be able to render those states directly instead of asking teams to maintain a second preview API or catalog.

What changed

• Adds the @vizzly-testing/swift CLI plugin and vizzly previews command.
• Builds the real iOS app, discovers generated preview registries, renders each preview in a booted Simulator, and writes PNGs plus a versioned manifest.
• Auto-selects the project, shared scheme, and Simulator only when there is one safe choice. Ambiguous cases require an explicit value.
• Sends captured previews to a live local TDD session or a Vizzly cloud build, with an intentional local-only fallback.
• Exposes an isolated screenshot client through the stable plugin API so plugins can use the existing screenshot server without shared client state.
• Protects managed output from incomplete, changed, duplicate, or unrelated files before replacing it.
• Packages the preview plugin with the Swift client and exercises the native fixture in the Swift release workflow.
• Rewrites the Swift docs around two clear paths: XCTest screenshots and stock SwiftUI preview capture.

Compatibility

The native renderer currently supports Xcode 26.6, arm64 iOS Simulators, iOS 17 or newer, scene-based apps, Debug builds, and previews without traits. The command checks the Xcode version and fails closed because preview interception depends on that release's Swift ABI.

Confidence

• The fixture discovers and captures both stock previews twice with stable image hashes, then proves changed and missing managed artifacts are refused.
• The complete Node test suite, Swift package tests, type tests, lint, format, CLI build, and npm tarball checks pass on the release Node 22 line.
• The Swift SDK uploads real PNGs through a temporary local TDD server and verifies a repeated screenshot against its baseline.