install-runtime.sh: provision a platform identity for new prefixes

When install-runtime.sh creates the prefix (first-time setup, regular or
Nix), it now runs configure-darling-platform.py --provision --write once
the runtime is stopped, so each new install gets its own synthetic serial,
MLB, UUID and ROM. A prefix counts as new the same way Darling decides it:
the directory did not exist before the first `darling shell`. Existing
prefixes keep their identity on reinstall and update.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/PLATFORM_IDENTITY.md

@@ -1,9 +1,12 @@
 # Explicit platform identity overrides
 
-By default, Darling keeps the existing host-derived UUID and `DARLING-` serial.
-No override file is generated by installation or launch. Import mode uses values supplied by the user. Explicit `--provision` mode can
-generate synthetic identifiers; it does not issue authentic Apple identities
-or change CPU, GPU, or security metadata.
+First-time setup (`scripts/install-runtime.sh` creating a new prefix) runs
+`--provision --write` once, so each new prefix gets its own synthetic identity.
+A prefix without saved identity files keeps the host-derived UUID and
+`DARLING-` serial; launching never generates an override. Import mode uses
+values supplied by the user. `--provision` generates synthetic identifiers; it
+does not issue authentic Apple identities or change CPU, GPU, or security
+metadata.
 
 Preview an OpenCore `config.plist`, a flat GenSMBIOS JSON file, or an existing
 `darling-smbios.conf` without changing the selected prefix:
@@ -89,9 +92,9 @@ python3 tools/configure-darling-platform.py --prefix /absolute/prefix --provisio
 ```
 
 Launch Darling normally afterwards. This requires the updated iokitd from this
-PR; the config tool alone cannot update an older running daemon. Provisioning
-is never called automatically by installation or launch. The one exception is
-`scripts/update.sh`: after installing, it runs
+PR; the config tool alone cannot update an older running daemon. Besides
+first-time setup above, provisioning runs automatically in one other case:
+after installing, `scripts/update.sh` runs
 `configure-darling-platform.py --replace-known-defaults --write`, which
 provisions the prefix only if its saved identity still contains the shared
 serial or UUID below. Prefixes without saved identity files, or whose saved

scripts/install-runtime.sh

@@ -16,6 +16,9 @@ if [ -d build/venv/bin ]; then PATH="$repo/build/venv/bin:$PATH"; export PATH; f
 # A server killed by the base install leaves a stale .init.pid that makes darling shell fail.
 python3 build/runtime/tools/ensure-darling-runtime.py
 # Initialize the normal user-owned prefix before installing overrides.
+# Darling treats a missing prefix directory as new; only then is an identity generated below.
+new_prefix=
+[ -e "$prefix_dir" ] || new_prefix=1
 darling shell /usr/bin/true
 # The prefix has no /private/tmp of its own, so the guest falls through to the root-owned
 # installed layer and every write there (the Riot installer's temp files) fails with EACCES.
@@ -26,6 +29,12 @@ chmod 1777 "$prefix/private/tmp"
 python3 build/runtime/tools/ensure-darling-root-certificates.py || \
   echo 'Darling system root store not installed; the launcher retries it' >&2
 python3 build/runtime/tools/stop-darling-runtime.py
+# Give a new prefix its own synthetic serial, MLB, UUID and ROM instead of the host-derived defaults.
+# Existing prefixes keep their identity; update.sh only replaces the old shared serial and UUID.
+if [ -n "$new_prefix" ]; then
+  python3 tools/configure-darling-platform.py --prefix "$prefix_dir" --provision --write || \
+    echo 'Platform identity not provisioned; run tools/configure-darling-platform.py --provision --write' >&2
+fi
 sh build/runtime/tools/install-riot-presentation-runtime.sh
 sh build/runtime/tools/install-riot-gpu-runtime.sh
 # darling-lol perf: build and install optimized libc/libc++/libplatform.