Add a Kind runtime backing (cyber pack) #189

Context

OpenRange spawns the runtime that backs an entrypoint kind through a
RuntimeBacking plugin (see src/openrange/core/runtime_backing.py).
The cyber pack today realizes a graph into a single Python app.py
that mounts every service on one ThreadingHTTPServer, dispatched
in-process by path prefix. That's enough to make vulns fire, but it
collapses something the cyber pack is fundamentally about: services
on different network positions.

The cyber community lives in Kubernetes. K8s primitives —
Deployments, Services, NetworkPolicies, Pods — map directly onto the
pack's ontology (service, network, connected_to). Defenders see
K8s in their day jobs; making the runtime match that model is what
makes generated worlds feel real.

What this issue tracks

Add a Kind-based runtime backing for the cyber pack:

• The pack's realizer emits Kubernetes manifests (Deployments,
  Services, NetworkPolicies) in addition to (or instead of) the
  single-process app.py.
• A KindBacking (or similar) brings up a local Kind cluster, applies
  the manifests, exposes the public service to the agent, and tears
  the cluster down on episode stop.
• Internal services are reachable only from other services in the
  cluster — defenders' NetworkPolicies actually enforce.
• Vulns still fire end-to-end (SQLi, SSRF, broken-authz tests pass).

Production-cluster deployment (real EKS / k3s / on-prem) is the same
manifest output applied to a non-ephemeral cluster — different
cluster context, different lifecycle, same realizer. Tracked as
Phase 3 below.

Why it matters

Real exploit chains pivot across network boundaries. SSRF that lets
the agent reach an "internal" metadata service is interesting because
the agent can't reach it directly. Without K8s-shaped network
isolation, the attack model is degenerate. With Kind, generated
worlds look (to both offense and defense agents) like the
infrastructure they'd actually face.

It also makes the dual-mode story (#191) much cleaner: defenders'
actions (close port, rotate credential) become K8s API calls;
offenders' pivots happen across real NetworkPolicies.

Where to start

• src/openrange/core/runtime_backing.py — the RuntimeBacking
  protocol with start / stop / interface / run_check /
  checkpoint / restore hooks.
• src/openrange/core/backings.py — the existing HTTPBacking (the
  reference implementation, single-process).
• src/openrange/packs/cyber_webapp_offense_v1/codegen/ — current
  codegen produces one app.py. Kind backing needs the realizer to
  emit per-service container images (or per-service Pod manifests
  built from one shared image with different command args) plus
  Kubernetes resources tying them together.
• Kind docs: https://kind.sigs.k8s.io/

Suggested approach

Phase 1 — single-host Kind cluster:

• Realizer emits a Dockerfile or per-service entrypoint scripts.
• KindBacking creates an ephemeral Kind cluster per episode.
• Public service exposed via NodePort or port-forward; internal
  services not reachable from outside.
• Tear-down on episode stop.

Phase 2 — make it fast enough:

• Per-episode cluster creation is slow. Pool clusters, or share one
  cluster across episodes by namespace, depending on what works.

Phase 3 — production cluster:

• Same manifest output applied to a non-ephemeral cluster (EKS / k3s
  / on-prem). Manifest field for cluster context
  (runtime.k8s.cluster: ...) drives whether the backing spins up
  ephemeral Kind or targets an existing context.
• Operational concerns Kind doesn't have: RBAC, secret management,
  observability across persistent state, no per-episode teardown.

Acceptance

Phase 1:

• A cyber world realizes into Kubernetes manifests.
• A KindBacking brings up a Kind cluster, applies the manifests,
  the agent reaches the public service, internal services are NOT
  reachable from outside the cluster.
• Vulns still fire end-to-end (existing functional tests pass).
• An SSRF exploit on the public service can pivot to an internal
  service — and that pivot is observable in K8s logs, not just
  in app logs.

Notes

The backing protocol's checkpoint / restore hooks can be naive
at first (kill cluster, recreate from manifests — same as today's
HTTPBacking). Real K8s state snapshotting is its own issue (#205).

Kind requires Docker. For a no-Docker fallback (CI / fast local dev
where realism doesn't matter), see #91 (synthetic backing).