store: centralize Fruix path naming

docs/GUIX_DIFFERENCES.md

@@ -197,6 +197,51 @@ So if you come from Guix, assume that Fruix now has:
 - explicit generation metadata roots
 - a real but still modest installed-system switch/rollback UX
 
+## 7. Fruix keeps Guix-like store semantics, but not Guix/Nix hash-prefix machinery exactly
+
+Fruix still uses immutable store paths under:
+
+- `/frx/store`
+
+and it still treats a store path as a deployment identity boundary.
+
+But Fruix now intentionally differs from Guix/Nix in how the visible store-path prefix is constructed.
+
+Current Fruix policy is:
+
+- centralize store-path naming behind shared helpers
+- hash a small semantic identity record rather than copying Nix's historical path-hash formula exactly
+- include at least:
+  - object kind
+  - logical/display name
+  - output name
+  - payload or manifest identity
+  - hash-scheme version marker
+- truncate the visible SHA-256 prefix to **160 bits**
+- render that visible prefix as **40 hex characters**
+
+Why Fruix does this instead of copying Guix/Nix exactly:
+
+- the main goal was shorter store prefixes, not Nix compatibility for its own sake
+- distinct outputs should have distinct identities because `out`, `lib`, `debug`, and `doc` are semantically different artifacts
+- Fruix wanted one central policy point that can be swapped later without touching every materializer again
+- Fruix did **not** want to inherit Nix's legacy details unless they provide clear value here
+  - custom base32 alphabet and bit ordering
+  - compressed/XOR-folded path hashes
+  - exact historical `output:out` / `source` path-hash conventions
+
+So compared with Guix:
+
+- the important semantic property is the same:
+  - different store objects should get different immutable identities
+- the exact printable prefix algorithm is intentionally simpler in Fruix today
+
+For Guix-familiar operators, the practical takeaway is:
+
+- still think of `/frx/store/...` paths as immutable deployment identities
+- do **not** assume Fruix store prefixes are byte-for-byte comparable to Guix/Nix ones
+- expect Fruix to prefer a simpler, centralized naming policy unless exact Guix/Nix behavior becomes necessary later
+
 ## 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.