## Why

The dedicated SCUM Run can register successfully, but a failed or draft server has no visible Platform action that submits its existing deployment definition. Operators therefore see an idle Run startup log and cannot advance the installation workflow.

## What Changes

- Add an explicit Deploy / Retry deploy control to the server detail actions for draft and failed servers.
- Submit the existing protected deployment definition through the existing authenticated deployment API, using the current config version and a fresh idempotency key.
- Present the queued deployment result in the normal operation feedback and refresh the server/job view.

## Capabilities

### New Capabilities

- `server-deployment-trigger`: Operator-facing dispatch of an already-configured draft or failed server deployment after its dedicated Run registers.

### Modified Capabilities

- None.

## Impact

- Affects `platform_web/pages/ServerDetailPage.tsx` and its focused UI tests.
- Reuses the existing `POST /api/v1/server-instances/{id}/deploy` contract; no new server API, remote access, credentials, or host data are introduced.