native-build: promote results into store objects

docs/GUIX_DIFFERENCES.md

@@ -274,6 +274,26 @@ The practical Fruix takeaway is:
 - the development overlay makes native base work possible inside the system
 - but real guest self-hosted base builds still need their own stricter build contract
 
+Fruix now also makes an explicit distinction between:
+
+- mutable native-build staging/results under:
+  - `/var/lib/fruix/native-builds`
+- immutable promoted native-build identities under:
+  - `/frx/store`
+
+So a guest self-hosted run can stage a result tree locally, while the host can later promote that result into first-class Fruix store objects such as:
+
+- `/frx/store/...-fruix-native-world-...`
+- `/frx/store/...-fruix-native-kernel-...`
+- `/frx/store/...-fruix-native-headers-...`
+- `/frx/store/...-fruix-native-bootloader-...`
+- `/frx/store/...-fruix-native-build-result-...`
+
+Compared with Guix, this is a more explicit split between:
+
+- a mutable result/staging area for native build execution
+- and the immutable store identities that Fruix treats as the real promoted result
+
 ## Where Fruix is intentionally trying to improve on Guix's representation
 
 Fruix is not trying to improve on Guix's core semantics. Guix already got those right.