Require CLI + API key for image publish and deploy to the public platform

Normal users should not be allowed to docker push directly to the public MCP Runtime platform registry.

Instead, publishing and deployment to the public platform should go through MCP Runtime commands that
authenticate with an API key and enforce platform policy.

## Problem

Right now the public platform model is too close to raw registry access. If users can push images directly with
docker push, the platform loses control over:

- who is publishing
- what metadata is attached to the image
- how publish authorization is enforced
- auditability of image publishing
- validation before deployment
- separation between publishing an image and deploying it to the public platform

For the public platform, image publishing and deployment should be controlled platform operations, not generic
registry writes.

## Desired behavior

For the public MCP Runtime platform:

- Normal users cannot docker push directly to the public registry
- Users must use the MCP Runtime CLI to publish an image
- The CLI requires an API key or equivalent platform credential
- The CLI performs the authenticated push on behalf of the user
- After publishing, users use a separate CLI command to deploy that published image to the platform
- Deployment should reference a published/approved image rather than allowing arbitrary direct registry writes

Expected flow:

1. User authenticates with MCP Runtime CLI using platform credentials
2. User runs a CLI command to publish the image to the public platform
3. Platform validates/authenticates the request and stores audit metadata
4. User runs a separate CLI command to deploy that image to the public platform

## Proposed CLI model

Example shape only:

mcp-runtime auth login --api-key
mcp-runtime registry push --image --server
mcp-runtime server deploy --server --image

Or equivalent commands if naming differs.

## Scope

- Public hosted platform only
- Block direct end-user docker push access to the public registry
- Require authenticated CLI-based publish flow
- Require separate deploy step after publish
- Ensure publish and deploy are auditable and policy-controlled
- Return clear errors when users try unsupported direct-push flows

## Acceptance criteria

- A normal user cannot publish to the public platform via raw docker push
- A normal user can publish through MCP Runtime CLI with a valid API key
- A normal user cannot publish through CLI without valid authentication
- Publish and deploy are separate operations
- A published image can be deployed through a second CLI command
- Publish and deploy actions are recorded in platform audit/logging
- Documentation explains the supported public-platform workflow clearly

## Why this matters

This keeps the public platform opinionated and governable:

- controlled publishing path
- stronger auth and audit
- consistent metadata and validation
- clearer separation between build, publish, and deploy
- less registry misuse on the hosted platform

## Open questions

- Should direct registry access be blocked for all non-admin users or for everyone on the public platform?
- Should admins still have a break-glass direct push path?
- Should publish create a platform-managed immutable image reference or artifact record?
- Should deploy only allow images published through the platform, or also approved existing refs?