## Why

Server management is the next first-party workflow after the console shell, plugin registry, run job channel, log ingest, and artifact transfer are available. Operators need a complete platform-mediated path to create a server instance from an installed game plugin, start it, stop it, and observe the resulting lifecycle state without exposing run internals to the browser or plugin pages.

## What Changes

- Add server lifecycle action APIs for create/install, start, and stop workflows.
- Dispatch lifecycle work through the existing platform job channel using bounded job metadata and idempotency keys.
- Enforce plugin, run endpoint, instance state, and optimistic config-version validation before lifecycle dispatch.
- Project lifecycle job state back onto server instances so the platform and frontend can show actionable states.
- Add frontend server management views and API client methods for create, start, stop, refresh, and workflow status.
- Add run-side lifecycle executor support for installing, starting, and stopping server jobs without exposing host paths, raw credentials, or direct sockets.

## Capabilities

### New Capabilities

- `server-management-workflows`: Platform-mediated server instance create, start, stop, and status workflows across `platform/`, `run/`, and `platform_web/`.

### Modified Capabilities

- None.

## Impact

- Affects `platform/` domain, DTO, validator, service, repository, API handlers, route docs, and protocol docs for server lifecycle operations.
- Affects `run/` protocol/client/executor code for lifecycle job handling.
- Affects `platform_web/` API types/client methods, route/page contracts, server management components, tests, and browser walkthrough.
- Reuses existing game plugin registry, run control, run job, log ingest, and artifact transfer contracts; does not add billing, cloud host sales, raw AI key exposure, host-path exposure, or direct plugin-to-run access.