k8s-runtime agents have zero ACP network exposure — Deployment only, no Service/port-forward #155

What's broken

K8sDriver::apply (crates/oabctl/src/k8s_driver.rs:324-360) only builds and
applies a Deployment (build_deployment, line 180). It never creates a
Service, NodePort, Ingress, or anything else that exposes a pod's ACP
port outside the cluster. The AppliedService it returns always has
webhook_urls: Vec::new() (line 355) — that field is never populated for
this driver, unlike the ECS path (apply.rs + ingress.rs, which does
build real webhook/API-Gateway URLs into that same field).

Net effect: a k8s-runtime agent gets an ACP auth key written into its
agents.toml/secret (same as ECS), but there is no address to put next to
it — nothing in the cluster forwards traffic to the pod's ACP port. Found
while live-testing + Add instance against a real cluster today (deployed
pod oab-artemis, confirmed via kubectl describe/agents.toml that the
key is configured but there's no reachable endpoint) — and it looks like
this was also silently true for the earlier k8s test agent ("seaturtle").

This blocks Studio's k8s chat panel work ([[studio-remote-verify-topology]]
in Orca's memory / the ACP-chat effort) for k8s fleets specifically — ECS
fleets aren't affected (ingress.rs already wires webhook URLs there).

Two candidate fixes (undecided — this is why this is an issue before a PR)

1. Real Service object, exposed via whatever the target cluster gives
   us locally (e.g. OrbStack's automatic localhost port mapping for
   NodePort/LoadBalancer services). Simple, standard k8s, but "reachable
   from the operator's machine" depends on the cluster/environment doing
   that mapping — works out of the box on OrbStack, not guaranteed on every
   cluster (bare NodePort needs node IP reachability; no ALB-equivalent here
   unless we also stand up an Ingress controller).
2. Studio-side dynamic port-forward via the kube crate (same one
   k8s_driver.rs already depends on) — Studio opens a forwarded connection
   to the pod's ACP port on demand when a k8s agent's console/chat is
   opened, no cluster-side networking object needed. Works on any cluster
   Studio has API access to (no assumption about NodePort/LB support), but
   the tunnel only exists while the console session is open — a different
   lifecycle than ECS's always-on ingress URL.

Related: #104, #111 (k8s fleet onboarding UX — this issue is the networking
layer underneath that work). Needs a decision (Service vs. port-forward, or
both for different use cases) before scoping a PR.