feat(bundle): ship a game as a macOS .app, with a splash it controls

`ludic build` produces a program. Double-clicked it opens a Terminal window, it
wears the generic executable icon, it calls itself whatever the file is called,
and it carries none of its assets. `ludic bundle` produces an application.

Everything it needs is in package.ludic, so the command takes no arguments: an
Info.plist and PkgInfo from `app` lines, an .icns built by sips and iconutil at
all ten sizes macOS asks for from a single source PNG, the asset pack in
Contents/Resources, and an ad-hoc signature - which is not optional on Apple
silicon, where an unsigned binary is killed rather than warned about. The bundle
identifier falls back to the package path reversed, so a project that never
thinks about it still gets a defensible one instead of two apps sharing a key
Launch Services hangs the Dock, saved state and permissions off.

A bundled game is moved to ~/Library/Application Support/<name> before main,
because Finder starts a .app with its working directory at "/" where no save
could ever be written. Reads come out of the pack, writes land somewhere real
and per-user, and the game's save code needs no change and no platform
knowledge.

The splash is the other half of looking like an application. A game that loads
165 MB spends a visible moment doing it with nothing on screen, which from the
outside is indistinguishable from a launch that failed. splash_show puts a
borderless window up from the same constructor that mounts the pack - before
main, so it appears while the process is still starting rather than after the
slow part it exists to cover - and reads the artwork out of the pack like any
other asset. It turns the run loop enough times to be mapped and composited
there and then; once composited the backing store survives a busy main thread,
so it stays up for the whole load.

Nothing hides it automatically. Only the game knows when its first real frame is
ready, and a splash that vanishes before that leaves the same black gap it was
covering, so the game calls App.splash_hide(). Headless there is no splash and
the call lowers to nothing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -60,9 +60,9 @@ ludic run            # compiles src/main.ludic and opens a native window
 ```
 
 `ludic new` writes a manifest, a program that already moves something on screen,
-and a test. `ludic build` stops at the binary — one self-contained executable
-with nothing to ship beside it. Rendering is deterministic, so a frame can be
-produced without a window, which is what CI diffs:
+and a test. `ludic build` stops at the binary; `ludic bundle` goes on to the
+thing you can actually give someone. Rendering is deterministic, so a frame can
+be produced without a window, which is what CI diffs:
 
 ```bash
 ludic test
@@ -114,6 +114,28 @@ bin/ludic-dev test      # the regression suite
 [API reference](https://workshopsoft.pages.workshopsoft.io/ludic/api.html)
 documents every symbol on its own page.
 
+## Shipping
+
+A built binary is a program, not an application: it opens its assets by a path
+relative to the working directory, so it runs from the project root and nowhere
+else, and it wears the generic executable icon.
+
+```bash
+ludic pack      # every asset the game opens, into one .lpak
+ludic bundle    # ...and that, the binary, an icon and the metadata, as a .app
+```
+
+Nothing about how the game is written changes. `gltf_load("assets/kit/hiker",
+…)` reads a file during development and a run of bytes inside the bundle once
+shipped, and cannot tell which — the pack is spliced in at `file_open`, the one
+place every asset in a Ludic program comes through. A bundled game also gets a
+boot splash it controls (`App.splash_hide()`) and a writable home under
+Application Support, because Finder starts a `.app` at `/` where no save could
+be written.
+
+Without a pack beside it — which is every `ludic run` — nothing mounts and every
+open goes to the filesystem exactly as before. See [docs/SHIPPING.md](docs/SHIPPING.md).
+
 ## Packages
 
 Dependencies are identified by URL, resolved with minimal version selection, and