Emit the iOS launch image set whole

[unlocdavid]

Follow-up to #159, which was closed with an invitation to raise anything in core that made building the plugin harder. The splash behavior now lives in unlocnl/nativephp-enhanced-splash; this is one of the things that turned up while building it.

It stands on its own as a bug, though — no plugin needed to hit it.

installIosSplashScreen() writes Contents.json and copies the app's splash variants into LaunchImage.imageset, but never clears the directory first. The set that ends up in the build is therefore the union of every build that came before it.

Two consequences:

1. A dropped variant keeps shipping. Remove public/splash-dark@3x.png and rebuild: it is gone from Contents.json, but the file is still in the image set and still in the app.

2. Content core did not write survives into a set that no longer lists it. This is the one that bites plugins. A plugin that substitutes a vector launch image writes splash.svg into the set; the next build rewrites Contents.json to list the PNGs again and leaves the .svg sitting there. That is exactly the mixed bitmap / "Any" scale combination the code immediately above this goes out of its way to avoid:

error: Image set has a child with bitmap content and the "Any" scale. The image set also has children with specific scales...

The change

Clear the image set before writing it, so it is emitted whole.

Only when there is artwork to replace it with — the clear sits after the empty($foundVariants) early return, not before it. The installed project ships a default LaunchImage.imageset, and an app with no splash of its own keeps it.

Why this helps plugins

A plugin that replaces a generated asset needs to be able to put it back when its config changes. For files core installs verbatim it can copy core's own copy back. For this set there is no such source — it is generated from the app's public/splash*.png — so today a plugin has to snapshot core's output into a private directory inside the build tree on first run, purely so it can restore it later. That stash is only necessary because the next build does not start clean.

With this change it does: whatever a plugin writes into the set, core takes the set back whole on the next build, and an app with no artwork keeps the shipped default. In the plugin this came out of, it removed the entire stash mechanism.

Testing

tests/Unit/Concerns/InstallsSplashScreenTest.php — covers the dropped variant, foreign content, and the default set being left alone when the app ships no splash. The first two fail without the change.

[shanerbaner82]

Nice, focused fix. Two cleanup boundaries need handling before merge:

• Guard a symlinked LaunchImage.imageset; recursive deletion can erase the link target.
• Cover custom → no splash, which currently leaves the previous custom image shipping.

Once those edges are covered, this should be straightforward to merge.

[unlocdavid]

Both edges are covered.

Symlinked set. File::deleteDirectory() gates on is_dir(), which resolves the link — it guards nested symlinks but not the top-level path, so the target's contents would go. Clearing now unlinks a symlinked set instead of recursing through it; the target is untouched and core gets a real directory back.

Custom → no splash. The early return on "no artwork found" was leaving the previous custom image shipping forever. That path now restores the set a fresh install ships, from resources/xcode/NativePHP/Assets.xcassets/LaunchImage.imageset. Clearing to empty was not an option — LaunchScreen.storyboard and SplashView.swift both reference the LaunchImage asset.

Two tests added for these; both fail against the previous revision (the symlink one shows the target's file erased). Full unit suite green.