native-build: introduce executor model

docs/system-deployment-workflow.md

@@ -337,7 +337,7 @@ Current metadata split:
 
 The promoted store objects record explicit Fruix-native metadata including at least:
 
-- executor / executor-version
+- executor kind / name / version
 - run-id / guest-host-name
 - closure path
 - source store provenance
@@ -353,6 +353,42 @@ This is the current Fruix-native answer to the question:
 - where should immutable native-build identity live?
   - `/frx/store/...`
 
+### Native-build executor model
+
+Fruix now has an explicit executor model for native base builds.
+
+Current executor kinds are:
+
+- `host`
+- `ssh-guest`
+- `self-hosted`
+
+and the intended future extension points are:
+
+- `jail`
+- `remote-builder`
+
+The important change is architectural:
+
+- declared source identity stays the same
+- expected artifact kinds stay the same
+- result/promotion metadata shape stays the same
+- only the executor policy changes
+
+So “where the build runs” is now treated as executor policy rather than as a separate native-build architecture each time.
+
+Current end-to-end validated executors for the staged-result-plus-promotion model are:
+
+- `ssh-guest`
+- `self-hosted`
+
+Both now converge on the same Fruix-native flow:
+
+1. run the build under a selected executor
+2. stage a result root under `/var/lib/fruix/native-builds/...`
+3. emit the same promotion/provenance shape
+4. promote the result into immutable `/frx/store/...` objects
+
 ## Deployment patterns
 
 ### 1. Build-first workflow