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/40-claim-rejected.yaml

@@ -0,0 +1,18 @@
+# NEGATIVE demo: this claim carries spec.env, which the template's
+# envVarsInjectionPolicy: Disallowed rejects. The claim never binds a
+# sandbox — inspect it to see the rejection (step 6 of the README).
+#
+# Why a platform wants rejection over acceptance: env injection forces a
+# cold start that bypasses the warm pool, silently turning a ~2s signup into
+# a cold provision. Disallowed turns that mistake into a loud error.
+apiVersion: extensions.agents.x-k8s.io/v1beta1
+kind: SandboxClaim
+metadata:
+  name: dsh-mallory
+  namespace: dsh-demo
+spec:
+  warmPoolRef:
+    name: dsh-pool
+  env:
+    - name: SNEAKY_OVERRIDE
+      value: "should-not-work"