Helm chart and minimal hub/broker container image for Kubernetes deployment

## Problem / Motivation

I want to deploy to kubernetes, I will produce an helm chart no matter what, to make sure everyone don't have todo it I can spend the time building one and make it something everyone can use.

I understand if you think it's to early to have to maintain a helm chart, but it would also help with on-boarding of more users to the project. The main maintaince burdon would probably adding args to the entrypoint, but we can make that very general in the helm chart so it's up to the user to add any config they want witout extra validation from the chart.

For production Kubernetes deployments, users need:
1. A minimal container image containing the `scion` binary + embedded web assets (the existing agent images in `image-build/` are designed for agent containers, not the hub server)
2. A Helm chart that deploys the hub/broker with proper configuration, secrets, persistence, health checks, and RBAC

Of course the container and helm chart would be sepreate PRs

## Proposed Solution

### 1. Minimal Hub/Broker Container Image

Build and publish a minimal container image for the `scion` server binary using [ko](https://ko.build/). Since the binary is already pure Go (`CGO_ENABLED=0`), ko is a natural fit:

- Produces minimal, distroless-based images with no shell or package manager
- Handles multi-arch (amd64/arm64) natively
- Integrates with existing GitHub Actions release workflow
- Makes SBOM generation and image signing straightforward to add later (cosign/syft)

The image only needs the `scion` binary with embedded web assets (built with `go build ./cmd/scion` — same binary serves hub, broker, and CLI). Entrypoint would be the `scion` binary directly.

**Publish to:** `ghcr.io/googlecloudplatform/scion` (or `ghcr.io/googlecloudplatform/scion-server` to distinguish from agent images)

**Trigger:** On tag push (alongside the existing `build-release.yml` workflow)

### 2. Helm Chart

Provide an helm chart as part of the release flow, It would be built using OCI so no index.yaml needed....

### Architecture context

Current constraint: SQLite limits the hub to a single replica. This is a known temporary limitation. [PostgreSQL support is planned](https://github.com/GoogleCloudPlatform/scion/issues/53), which would make the hub stateless and enable multi-replica scaling. The `EventPublisher` interface already has a designed path to `PostgresEventPublisher` using `LISTEN/NOTIFY` (see `.design/hosted/web-realtime.md`, Stage 5).

## Alternatives Considered

- **Kustomize**: Simpler but less flexible for the configuration surface area needed (two modes, many optional features). Helm's templating is better suited here.
- **Dockerfile instead of ko**: ko is preferred because the binary is pure Go (`CGO_ENABLED=0`), ko produces smaller/more secure images, and it makes multi-arch, SBOM, and signing trivial to add.

## Additional Context

- Design doc for event scaling path: `.design/hosted/web-realtime.md`

Start by reading the existing agent images in image-build/, the scion entry point in cmd/scion, and the release workflow build-release.yml. Review .design/hosted/web-realtime.md for the scaling context. Done means separate container and Helm chart work can deploy the hub/broker with configuration, secrets, persistence, health checks, RBAC, and tag-triggered release publishing.

Written by the indexing model from the issue text.