feat(repo)!: restructure around the dsh-harness image and one example per implementation

- the root Dockerfile is the primary artifact; versions.env is the single source of truth
- merge gateway-api/dsh-demo into examples/dsh-agents-as-a-service (manifests/, exposure variants)
- move the single-tenant template into examples/minimal-single-tenant
- publish the gateway as a nested package under the repository image
- mirror the DSH ref for release identities (first release dsh-v0.2.1-rc.2-r2)
- CI: lint/python/manifests/gateway-image, reusable multi-arch build, tag-driven release, weekly e2e
- docs: README, docs/{main-image,examples,gitflow,versioning}, example READMEs, AGENTS.md, governance
- SSO is opt-in again; gateway pull policy and cookie defaults match the documented demo

BREAKING CHANGE: example manifest paths, the gateway image name, and the removal
of deploy/ and gateway-api/ affect existing deployments; see the migration table
in README.md.

examples/dsh-agents-as-a-service/manifests/00-prereqs.yaml

@@ -0,0 +1,27 @@
+# DSH "Agents as a Service" — prerequisites: namespace + shared provider key.
+#
+# The dsh-provider-keys Secret is deliberately NOT committed with a usable
+# value. DEEPSEEK_API_KEY reaches every tenant sandbox (injected via envFrom
+# on the SandboxTemplate, stamped before any user exists — a warm-pool
+# constraint), so a real key committed here would be shared by every install
+# of this example. Generate a fresh value per install (README step 1;
+# scripts/e2e-kind.sh uses a throwaway):
+#
+#   kubectl -n dsh-demo create secret generic dsh-provider-keys \
+#     --from-literal=DEEPSEEK_API_KEY="sk-..."
+#
+# All the infrastructure in this example works without a real key; only
+# actual model calls need one.
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: dsh-demo
+---
+apiVersion: v1
+kind: Secret
+metadata:
+  name: dsh-provider-keys
+  namespace: dsh-demo
+type: Opaque
+# stringData:
+#   DEEPSEEK_API_KEY: "sk-your-key-here"