Add isolated kind dependency testbed

docs/spec/testing.md

@@ -0,0 +1,26 @@
+# Dependency testing
+
+Backend integration tests execute inside an isolated kind cluster so they use
+the same DNS and service routing boundaries as deployed Nuthatch components.
+The fixture provides PostgreSQL, Redis and DragonflyDB, Keycloak and ZITADEL,
+and Garage and VersityGW. Images and fixture tools are checksum or
+digest-pinned.
+
+`make check-dependencies` creates the complete fixture, verifies each released
+dependency image through its product interface, and destroys the fixture.
+`tests/kind/setup.sh` creates the same ready fixture for interactive test work;
+`tests/kind/destroy.sh` removes it. `NUTHATCH_TESTBED_RETAIN=1` retains a failed
+all-in-one run for inspection.
+
+The fixture uses `tests/kind/.runtime/kubeconfig` and the
+`kind-nuthatch-testbed` context. Every Kubernetes operation supplies both
+explicitly. Fixture lifecycle operations are serialized by a host-runtime lock
+shared across worktrees, and teardown is idempotent.
+
+All fixture credentials and data are synthetic. Test workloads use ClusterIP
+service names and do not require host port forwarding. The fixture does not
+read or change the user's Kubernetes context.
+
+The host provides rootless nerdctl and containerd at the versions recorded in
+`tests/kind/versions.env`, together with `ctr`, `curl`, `flock`, `jq`, and
+`sha256sum`. The fixture downloads its pinned kind and kubectl binaries.