Move SCUM lifecycle ownership to plugin

platform/domain/resources.md

@@ -111,12 +111,13 @@ Run sessions persist only a token hash, generation, status, expiry, capability f
 
 Installed `GamePlugin` records persist the validated manifest `runtimeProfiles` contract, including discovery, lifecycle, dependency/install, log, transport, and client-manager declarations. One server binding selects one declared lifecycle profile. Platform derives allowed and required logical keys; clients cannot assert `missingKeys` or `status`.
 
-SCUM plugins may additionally declare `runtimeProfiles.serverDeployments`. These
-profiles are versioned, freeze into a leased Run assignment, and contain only
-logical executable/config markers, field mappings, discovery markers, and
-verification checks. A server's `DeploymentProjection` stores bounded evidence
-from Run for operator views; protected paths, commands, credentials, process
-ids, and sockets never enter that projection.
+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.
 
 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.