feat(api): add tenant namespace provisioning and scoped MCPServer deploys

## Summary

Add platform-managed tenant namespace provisioning and scoped MCPServer deployment through MCP Runtime APIs. Normal users should not receive Kubernetes kubeconfigs, ServiceAccount tokens, or direct Kubernetes API access. All tenant actions should go through the platform API/CLI using an API key or platform session.

Related design thread: #14

## Desired model

```text
User/API key/session
-> platform auth
-> tenant/workspace
-> allowed namespace(s)
-> platform API writes MCPServer CRD
-> operator deploys workload in that namespace
```

Kubernetes ServiceAccounts remain internal platform implementation details:

- `mcp-runtime-api`: platform API identity with permission to create tenant namespaces and write MCP Runtime resources.
- `mcp-runtime-operator`: operator identity for reconciling MCPServer resources.
- `mcp-workload`: optional default ServiceAccount inside each tenant namespace, used by deployed MCP server pods, not exposed to users.

## API changes

Add tenant namespace lifecycle APIs. Exact route names can change, but the product capability should be explicit.

### Create tenant namespace

```http
POST /api/runtime/namespaces
Authorization: Bearer
Content-Type: application/json

{
"name": "acme-tools"
}
```

Behavior:

- Authenticates the API key/session.
- Resolves tenant/workspace from the auth identity.
- Validates requested namespace name.
- Applies a platform prefix or canonical name, for example `mcp-tenant--`.
- Rejects reserved namespaces and names outside policy.
- Creates the namespace with labels/annotations.
- Applies baseline ResourceQuota, LimitRange, optional NetworkPolicy, and default workload ServiceAccount.
- Stores ownership mapping: tenant/workspace -> namespace.

Suggested response:

```json
{
"name": "mcp-tenant-acme-tools",
"displayName": "acme-tools",
"tenantID": "acme",
"status": "Ready"
}
```

### List tenant namespaces

```http
GET /api/runtime/namespaces
Authorization: Bearer
```

Returns only namespaces owned by the tenant/workspace for the caller.

### Get tenant namespace

```http
GET /api/runtime/namespaces/{namespace}
Authorization: Bearer
```

Must enforce that `{namespace}` belongs to the caller's tenant/workspace.

### Delete tenant namespace

```http
DELETE /api/runtime/namespaces/{namespace}
Authorization: Bearer
```

Open design decision: whether deletion is tenant self-service, admin-only, or requires namespace to be empty.

### Deploy MCPServer into a tenant namespace

Existing or new server deploy endpoint should enforce namespace ownership:

```http
POST /api/runtime/servers
Authorization: Bearer
Content-Type: application/json

{
"namespace": "mcp-tenant-acme-tools",
"name": "weather-tools",
"image": "registry.example.com/acme/weather-tools:v1"
}
```

Rules:

- API key/session must resolve to a tenant/workspace.
- Requested namespace must be owned by that tenant/workspace.
- API must not trust arbitrary `metadata.namespace` from user input.
- API creates/updates `MCPServer` only in the authorized namespace.
- Operator deploys workload only in the MCPServer CRD namespace.

## Authorization model

Implement or extend platform auth so API keys/sessions map to tenant/workspace identity and allowed namespaces.

Required checks:

- Normal users cannot access `mcp-runtime`, `mcp-sentinel`, `registry`, `traefik`, `kube-*`, `default`, or another tenant namespace.
- Tenant users cannot list or inspect namespaces outside their tenant.
- Admin users can list/manage tenant namespaces across the platform.
- Server push/deploy must fail if the namespace is not owned by the caller's tenant.
- Registry publish/deploy paths should use the same tenant/namespace ownership model.

## Namespace provisioning behavior

When creating a tenant namespace, platform should apply:

- DNS-1123 namespace validation.
- Reserved namespace denylist.
- Optional platform prefix, e.g. `mcp-tenant--`.
- Labels:
- `mcpruntime.org/managed=true`
- `mcpruntime.org/tenant-id=`
- optional `mcpruntime.org/workspace-id=`
- Annotations for owner/audit metadata where safe.
- Default `ResourceQuota`.
- Default `LimitRange`.
- Optional default-deny or platform-approved `NetworkPolicy`.
- Default workload ServiceAccount:

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: mcp-workload
namespace:
automountServiceAccountToken: false
```

Generated MCP server Deployments should use `serviceAccountName: mcp-workload` and `automountServiceAccountToken: false` by default.

## MCPServer / operator guardrails

The operator and/or admission validation must prevent namespace escape and unsafe pod customization.

Validate or restrict:

- `MCPServer` reconciliation deploys only into `metadata.namespace`.
- User-controlled spec fields cannot reference secrets/configmaps in another namespace.
- Users cannot choose arbitrary service accounts unless explicitly allowed by policy.
- No `hostNetwork`, `hostPID`, `hostIPC`.
- No privileged containers.
- No `hostPath` volumes.
- No dangerous capabilities by default.
- No arbitrary ingress host override that conflicts with another tenant or platform domain.
- Registry image refs are tenant-scoped or point to approved published artifacts.

## Registry / publish flow

Tie image publish and deploy to the same auth and namespace model.

Required behavior:

- CLI/API publish requires API key/session.
- Published image is associated with tenant/workspace and server name.
- Registry repo/path should be tenant-scoped, for example `//:`.
- Deploy should only accept images published by or approved for that tenant, unless admin policy allows external refs.
- Publish and deploy actions should emit audit events.

Related existing issue: #74

## CLI changes

Add or update CLI flows so users do not need direct Kubernetes credentials.

Possible shape:

```bash
mcp-runtime auth login --api-key
mcp-runtime namespace create acme-tools
mcp-runtime namespace list
mcp-runtime server push --namespace mcp-tenant-acme-tools --name weather-tools --image weather-tools:latest
mcp-runtime server deploy --namespace mcp-tenant-acme-tools --name weather-tools
```

CLI should call platform APIs, not `kubectl`, for tenant user workflows.

## UI changes

Tenant UI should support:

- creating a namespace/workspace target if allowed
- listing only owned namespaces
- choosing namespace during server deploy
- showing namespace-scoped MCP servers
- clear errors when a user tries to deploy outside their allowed namespace

Admin UI should support:

- listing all tenant namespaces
- seeing owner/tenant/workspace labels
- seeing resource/quota status
- reviewing namespace/server/publish audit activity

Related issues: #75, #76

## Audit and observability

Emit audit events for:

- namespace create/delete
- server push/publish
- server deploy/update/delete
- authorization denied because namespace is not owned by caller
- admin override actions

Event fields should include:

- user/API key identity label
- tenant/workspace
- namespace
- server name
- image ref where applicable
- action/result
- timestamp
- source interface: CLI/UI/API

## Tests

Add coverage for:

- namespace name validation and reserved namespace rejection
- tenant namespace creation applies labels/resources/default SA
- API key can list only owned namespaces
- API key cannot deploy MCPServer into another tenant namespace
- admin can view/manage across tenants
- server deploy writes MCPServer into the authorized namespace
- operator generated Deployment uses `mcp-workload` with `automountServiceAccountToken: false`
- unsafe MCPServer spec fields are rejected or ignored according to policy
- registry publish/deploy is tenant-scoped

## Documentation

Update docs for:

- tenant vs admin workflow
- namespace lifecycle API/CLI
- no direct Kubernetes access for normal tenant users
- internal platform ServiceAccount model
- default tenant namespace resources and isolation controls
- publish/deploy flow with API key authorization

## Acceptance criteria

- Normal tenant users can create/list their platform-managed namespaces through MCP Runtime API/CLI.
- Normal tenant users cannot receive or require Kubernetes tokens/kubeconfigs.
- Normal tenant users can push/deploy MCP servers only into namespaces owned by their tenant/workspace.
- Platform API rejects deploys into platform, Kubernetes system, default, or another tenant namespace.
- Operator deploys MCP server workloads only in the MCPServer CRD namespace.
- Tenant workload pods use a dedicated `mcp-workload` ServiceAccount with `automountServiceAccountToken: false` by default.
- Admin users can inspect/manage tenant namespaces and activity through admin APIs/UI.
- Audit events exist for namespace, publish, deploy, and denied authorization actions.
- Docs explain the model and supported workflows.