chore: remove legacy startup paths

docs/compat-removal-plan.md

@@ -67,11 +67,11 @@ backward-compatible behavior while migration settles.
 
 ## Remaining Migration Risks
 
-### Split service deployment is not yet the checked-in production default
+### Checked-in deployment artifacts still lag the development topology
 
 - The repo documents split-service local development clearly.
-- The checked-in production example still centers on `backend.main` and nginx
-  WebSocket proxying.
+- The checked-in deployment docs still center on historical nginx
+  WebSocket proxying rather than the active dev topology.
 - This is a topology mismatch to keep in mind when changing deploy docs or prod
   automation.
 
@@ -93,13 +93,13 @@ backward-compatible behavior while migration settles.
 Migration can be considered effectively complete when all of the following are
 true:
 
-1. Production deployment docs and scripts explicitly run the same split-service
-   topology used in development, or intentionally document a different stable
-   production topology.
+1. Deployment docs and scripts explicitly run the same split-service
+   topology used in development, or are removed from the repo.
 2. Critical read paths no longer require ambiguous fallback behavior to local
    module implementations.
 3. OpenClaw integration is documented as a stable contract with clear guidance
-   on when to use the WebSocket gateway versus the REST surface.
+   on when to use the WebSocket gateway versus the small set of CLI-backed
+   gateway read helpers.
 4. The frontend-service routing model is stable enough that direct-service and
    gateway-mediated paths are deliberate design choices rather than migration
    leftovers.
@@ -137,9 +137,6 @@ Recommended next action:
 These still have an operational reason to exist and should be documented rather
 than treated as accidental leftovers.
 
-- `backend.main`
-  - compatibility gateway/runtime process
-  - still relevant for websocket transport and current deploy topology
 - `runs/<run_id>/team_dashboard/*.json`
   - export/consumer compatibility layer
 - gateway-mediated websocket/event flow
@@ -147,8 +144,8 @@ than treated as accidental leftovers.
 
 Recommended next action:
 
-- keep these, but document them as intentional compatibility surfaces with
-  explicit ownership.
+- keep only surfaces with an active operational consumer, and avoid routing new
+  development through them.
 
 ### 3. Defer Until Topology Decisions Are Final
 
@@ -157,8 +154,8 @@ churn without simplifying the current runtime.
 
 - `workspaces/` design-time registry versus `runs/<run_id>/` runtime state
 - env-dependent service fallback behavior
-- checked-in deployment docs centered on `backend.main`
-- dual OpenClaw shapes: gateway integration and REST facade
+- checked-in deployment docs that have not yet been rewritten around split services
+- dual OpenClaw access patterns: gateway integration and CLI-backed read helpers
 
 Recommended next action: