v0.4.0 — interactive agents under the k8s fleet

Makes the PROSPERO_FLEET=k8s fleet interactive. Since 0.3.0 a k8s agent
could be launched from the dashboard but never talked to: the reply box renders
only for an agent that is both interactive and idle, and under the k8s
backend neither could ever be true. Closing that took a field on the
authoritative CRD (caliban-operator#28) plus both halves of the round-trip here,
and turned up a second defect — 0.3.3's agent-id decoupling had quietly broken
reply delivery and the 0.3.2 status overlay. Local behavior is unchanged.

Deploy note: requires the caliban-crds chart at >= 0.2.1. Older CRDs
have no spec.task.interactive, so the API server prunes the field at admission
and the flag never reaches the pod.

Added

• Interactive agents under PROSPERO_FLEET=k8s. The dashboard's
  interactive: true now survives the CR round-trip: build_calibantask
  writes spec.task.interactive (the field caliban-operator#28 added to the
  authoritative CRD) and spawn_spec_from_task reads it back into the
  SpawnSpec sent to the pod's caliband. Previously the flag was silently
  dropped at the CR boundary and the spawn spec hardcoded interactive: false,
  so a k8s agent could never await input and the dashboard reply box
  (interactive && idle) could never appear. Requires the caliban-crds chart
  at >= 0.2.1, or the API server prunes the field at admission
  (#163).

Fixed

• Operator replies and the interactive/idle overlay now target caliband's own
  agent id. #159 decoupled the agent id caliband assigns from prospero's CR
  name, but send_input still attached by CR name (404, reply lost) and
  overlay_pod_status still looked records up by id (silent miss, regressing
  #130's reply box). send_input now resolves the pod's agent via
  ensure_pod_agent, and the overlay matches each pod's record by endpoint
  rather than by id. The pre-existing tests used one string for both ids, so
  they passed while the real path was broken; the new tests use distinct ids
  (#163).