Add SCUM file management workbench

platform/domain/resources.go

@@ -1030,6 +1030,22 @@ type FileOperationDispatchResult struct {
 	Status           string
 }
 
+// DeclaredFileReadSnapshot is the redacted, bounded projection of a completed
+// files.read job for one plugin-declared logical file.
+type DeclaredFileReadSnapshot struct {
+	ServerInstanceID string
+	PluginID         string
+	Key              string
+	State            string
+	Content          string
+	Version          int
+	Checksum         string
+	SizeBytes        int64
+	JobID            string
+	ReadAt           time.Time
+	Reason           string
+}
+
 type RunCapacity struct {
 	MaxJobs               int
 	RunningJobs           int

platform/domain/resources.md

@@ -114,10 +114,13 @@ Installed `GamePlugin` records persist the validated manifest `runtimeProfiles`
 Plugin lifecycle assets are registered as manifest-declared files plus a
 content-bearing registration payload. Platform packages those assets into
 generated Run workspaces so plugin action refs such as `actions/install.json`
-and script refs such as `bin/scum-start.cmd` are available before the first
-install/start job. Game-specific install/update/start policy, including SCUM
-SteamCMD app IDs and launch flags, stays in the plugin asset bundle rather than
-in platform services or Run executors.
+and helper refs such as `bin/scum-install-update.cmd` are available before the
+first bootstrap job. Guided deployments whose selected lifecycle profile
+supports `process.start` may bootstrap through the plugin-owned start action so
+the script can install-if-missing and then launch the supervised process whose
+stdout/stderr feed the live terminal. Game-specific install/update/start policy,
+including SCUM SteamCMD app IDs and launch flags, stays in the plugin asset
+bundle rather than in platform services or Run executors.
 
 Bindings are used for action gating and future run-side profile resolution. File and MySQL metadata snapshots include them so a platform restart does not make a configured server appear complete or lose its selected profile. API responses expose only logical key names, configured/secret-backed flags, missing keys, and safe reasons. They never expose stored binding values, raw host paths, direct sockets, FTP/RCON passwords, SQL DSNs, component auth keys, or internal secret locations.
 
@@ -161,8 +164,8 @@ Dependency checks and installs are queued as run jobs with logical `dependencies
 
 Lifecycle workflow jobs use fixed capabilities:
 
-- `process.install`: dispatched by server create workflow and projects successful terminal results to `ready`.
-- `process.start`: dispatched by server start workflow and projects successful terminal results to `running`.
+- `process.install`: dispatched by install bootstrap workflows and projects successful terminal results to `ready`.
+- `process.start`: dispatched by server start workflow or guided supervised bootstrap and projects successful terminal results to `running`.
 - `process.stop`: dispatched by server stop workflow and projects successful terminal results to `stopped`.
 - `run.self-update`: dispatched by runtime distribution APIs with an approved artifact ref and checksum.
 - `dependencies.check`: dispatched by dependency check APIs for a declared probe key.