v0.26.0 — operational foundation pt.3: multi-runtime deploy (k8s/Helm/Flux + Docker Compose)

Third slice of the WS-007 operational foundation — a scaffolded service now has a deploy path for ≥2 runtime targets behind a deployment-target seam.

Multi-runtime deploy (#95)

• Target seam: a Target interface + registry; --deploy k8s,compose renders artifacts into the service repo. Adding a target = a new adapter (no core change). An ECS stub proves the seam is open.
• k8s/k3s (first-class): a framework-owned Helm chart is go:embed-ed in the tooling — devs never author or see it. The k8s target emits only a Flux HelmRelease + an OCIRepository source + a thin values.yaml overlay. The chart wires the whole foundation: liveness /healthz + readiness /readyz (#91), the config.ServerOptions env (#93), OTEL_* (#90), the DSN as a Secret, ingress, resource limits, and terminationGracePeriodSeconds.
• Docker Compose: docker-compose.yml (service + declared deps, e.g. Postgres) wired to the same config/health/observability surface, with stop_grace_period.
• Graceful shutdown: scaffolded main now uses signal.NotifyContext (SIGTERM/SIGINT) so Serve returns → graceful gRPC/HTTP shutdown + OTel flush + readiness-loop stop.

Hardening (#106)

• Coherence cleanup (single source for chart name+version) + a chart-ref drift guard test (emitted HelmRelease/OCIRepository must match the embedded Chart.yaml). helm/docker tests skip-when-absent; the embedded chart bytes are exactly what helm lint/helm template validate.

Dependency-light gate: the deploy feature adds no runtime dependency — production rendering uses text/template (no YAML lib); the deploy code is tooling-only. Artifacts are templates, not deps.