kind: replace the mesh-config node templating with a sam-node Helm chart

[kaisoz]

The kind dev environment templated each sam-node (and its optional example service) out of mesh-config.yaml + node.template.yaml via envsubst, which was hard to discover and different from how anyone deploys a node in a real cluster. This PR replaces that with a first-class chart and plain Helm workflows:

• New charts/sam-node: deploys one node — ServiceAccount, config ConfigMap (services + attenuation from values), Deployment with the sam-node container and an optional service container sharing localhost (rendered when service.image is set). controlPlaneUrl is required; audience defaults to sam-mesh-audience; the node API binds loopback by default. Covered by helm-unittest (make helm-test) and wired into make helm-lint.
• development/kind/run.sh deploys infrastructure only (control plane, router, console, Dex) — no sam-nodes. The cluster shrinks to one control-plane and two workers (one labeled sam-role: control-plane for the router); tmux shows control-plane and router panes.
• Examples become chart releases: each development/examples/* ships a values.yaml describing just its service, stacked on development/kind/sam-node.values.yaml (kind wiring). Deploying is docker build + kind load + helm install -f base -f example. The new chat-a2a example is migrated too.
• e2e deploys calc-mcp through the chart — CI now exercises the exact flow developers use. mesh-config.yaml, mesh-config.e2e.yaml, node.template.yaml, and all per-example sam-node-config.yaml files are deleted.
• Docs updated: dev kubernetes guide, development index, warm-agent-pool / gemini-buddy / chat-a2a use cases, and a pointer in the production kubernetes guide (the chart packages the same pattern as the hand-written manifests there).

[gemini-code-assist]

Code Review

This pull request introduces a new Helm chart, sam-node, to deploy SAM nodes with optional sidecar services, replacing the previous static node configuration templates. It also updates the local development scripts and documentation to use this new Helm-based deployment flow. The review feedback focuses on improving the robustness of the deployment and cleanup scripts—specifically by using label selectors for rollout checks and adding safety checks before directory deletion—and making the Helm chart more flexible by supporting optional ServiceAccount creation, custom names, and annotations.

[gemini-code-assist]

To prevent accidental deletion of critical directories (e.g., if DATA_DIR is empty or set to an unexpected path), it is highly recommended to perform a sanity check (ensuring the variable is non-empty and is a directory) before executing rm -rf.

Suggested change

	cleanup() { [[ -n "${NODE_PID:-}" ]] && kill "${NODE_PID}" 2>/dev/null || true; rm -rf "${DATA_DIR}"; }
	cleanup() { [[ -n "${NODE_PID:-}" ]] && kill "${NODE_PID}" 2>/dev/null || true; [[ -n "${DATA_DIR:-}" && -d "${DATA_DIR}" ]] && rm -rf "${DATA_DIR}"; }

[gemini-code-assist]

To make the Helm chart production-ready and flexible for cloud environments (where ServiceAccounts often require specific annotations for IAM/Workload Identity mapping, or where users might want to reuse an existing ServiceAccount), it is highly recommended to make the ServiceAccount creation optional and support custom annotations.

{{- if .Values.serviceAccount.create -}}
apiVersion: v1
kind: ServiceAccount
metadata:
  name: {{ default (include "sam-node.fullname" .) .Values.serviceAccount.name }}
  labels:
    {{- include "sam-node.labels" . | nindent 4 }}
  {{- with .Values.serviceAccount.annotations }}
  annotations:
    {{- toYaml . | nindent 4 }}
  {{- end }}
{{- end }}

[kaisoz]

Done

[aojea]

LGTM way simpler and easier to think about, there are some open comments, let me know if they need to be addressed or this is fine to merge as is