## Why

The current server workflow uses one `RunEndpoint` both as a pre-existing worker that builds and installs software and as the server-scoped Run binary generated after creation. This creates a bootstrap loop, permits multiple servers to share one endpoint despite the intended one-server/one-Run model, and leaves component registration insufficiently bound to its server.

## What Changes

- Add a server-scoped Run binding with an explicit lifecycle from draft, through target selection and Run registration, to deployment.
- **BREAKING** Separate a deployment target from the dedicated Run endpoint that controls one server; a selected target no longer immediately dispatches installation.
- Require a generated Run to register with the endpoint identity reserved for its server before deployment or runtime jobs can be dispatched.
- Reject endpoint reuse, mismatched component registration, and cross-server job access; revoke only the Run bound to the affected server.
- Update the server creation workflow to save a draft, describe the selected target accurately, and guide the operator through Run generation, registration, and deployment.

## Capabilities

### New Capabilities

- `server-scoped-run-binding`: Securely reserve, register, validate, replace, and revoke one dedicated Run endpoint for a server instance.
- `server-run-bootstrap-workflow`: Create a server as a draft and progress it through deployment-target selection, dedicated Run registration, and explicit deployment.

### Modified Capabilities

- None.

## Impact

- `platform/`: domain, DTOs, models/repositories, services, control registration, lifecycle dispatch, distribution build selection, validation, API documentation, and tests.
- `platform_web/`: API types, server creation/deployment workflow, Run builder status and focused tests.
- `run/`: independent repository coordination is required for the revised registration identity; this repository will only update its public contract.