system: add in-node build and reconfigure

docs/GUIX_DIFFERENCES.md

@@ -171,8 +171,10 @@ So compared with Guix-on-Linux intuition, Fruix operators should be more explici
 
 This remains the biggest operational gap, but it is no longer a complete gap.
 
-Installed Fruix systems now provide a small in-guest helper:
+Installed Fruix systems now provide a larger in-guest helper surface:
 
+- `fruix system build`
+- `fruix system reconfigure`
 - `fruix system status`
 - `fruix system switch /frx/store/...-fruix-system-...`
 - `fruix system rollback`
@@ -183,11 +185,14 @@ What this gives you today:
 - explicit rollback-generation tracking
 - in-place switching between already-staged closures on the installed target
 - rollback without reinstalling the whole system image again
+- a validated in-node build path that can read the embedded current declaration inputs
+- a validated in-node `reconfigure` path that can build a candidate closure locally and stage it as the next generation
 
 What it still does **not** give you yet compared with Guix:
 
-- a mature `reconfigure`-style workflow that builds and stages the new closure from inside the target system
+- a mature end-to-end `upgrade` story for advancing declared inputs automatically
 - automatic closure transfer/fetch as part of `switch`
+- a higher-level `deploy` workflow across multiple machines or targets
 - the broader generation-management UX Guix operators expect
 
 So if you come from Guix, assume that Fruix now has:
@@ -195,7 +200,8 @@ So if you come from Guix, assume that Fruix now has:
 - strong closure/store semantics
 - explicit install artifacts
 - explicit generation metadata roots
-- a real but still modest installed-system switch/rollback UX
+- a real installed-system build/reconfigure/switch/rollback surface
+- but not yet the fuller long-term node/deployment UX that Guix users may expect
 
 ## 7. Fruix keeps Guix-like store semantics, but not Guix/Nix hash-prefix machinery exactly