feat: deploy the agent — image, manifests, and the Flux plumbing

Two-stage Dockerfile: the runtime image carries neither uv nor a build
toolchain, runs as uid 10001, drops every capability and needs no writable
filesystem (verified with --read-only and no tmpfs).

k8s/ is what runs, dev/ is the Flux plumbing that applies it, self-managing
after three manual applies — the same shape every kong-* repo settled on.

Three choices worth naming:

- One namespace for the estate. What isolates an agent is its Keycloak client
  and the audiences it may request, not a namespace boundary.
- The GitRepository uses anonymous HTTPS rather than SSH with a Vault-held
  deploy key. The repo is already anonymously readable on gitea, so a key would
  guard nothing while adding two objects to create by hand before anything
  deploys. If the repos ever go private this becomes the kong-* SSH pattern.
- The lab CA certificate is committed. It is a certificate, never a key, and
  checking it in means the deployment has no hidden prerequisite.

replicas: 1 is a constraint, not a default — conversation history lives in the
process, so a second replica would route a user's "yes" to a pod that never saw
the question.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

dev/bootstrap-kustomization.yaml

@@ -0,0 +1,33 @@
+# Watches ./dev, so the GitRepository and the Kustomization below it reconcile
+# from git like any other manifest. It lives in ./dev itself, so it also manages
+# itself — the arrangement `flux bootstrap` sets up, which flux-operator does
+# not create, and the same one every kong-* repo now uses.
+#
+# It sits in the agents namespace, not flux-system: a sourceRef resolves in the
+# Kustomization's own namespace, and this is the agent team's to own.
+#
+# Three manual applies, once, to close the loop — nothing can watch ./dev until
+# the namespace and the source that serves it exist:
+#
+#   kubectl apply -f k8s/namespace.yaml
+#   kubectl apply -f dev/gitrepository.yaml
+#   kubectl apply -f dev/bootstrap-kustomization.yaml
+#
+# After that every file in this repo, this one included, reconciles from git.
+#
+# Sharp edge: with prune enabled, deleting flux-kustomization.yaml from git
+# deletes the Kustomization it defines, and that Kustomization's own prune then
+# removes the whole deployment. Correct GitOps behaviour, blast radius two
+# levels deep.
+apiVersion: kustomize.toolkit.fluxcd.io/v1
+kind: Kustomization
+metadata:
+  name: catalogue-agent-bootstrap
+  namespace: agents
+spec:
+  interval: 10m
+  sourceRef:
+    kind: GitRepository
+    name: catalogue-agent
+  path: ./dev
+  prune: true

dev/flux-kustomization.yaml

@@ -0,0 +1,14 @@
+apiVersion: kustomize.toolkit.fluxcd.io/v1
+kind: Kustomization
+metadata:
+  name: catalogue-agent
+  namespace: agents
+spec:
+  interval: 10m
+  sourceRef:
+    kind: GitRepository
+    name: catalogue-agent
+  path: ./k8s
+  prune: true
+  wait: true
+  timeout: 3m

dev/gitrepository.yaml

@@ -0,0 +1,19 @@
+# HTTPS with no credentials, unlike the kong-* repos which use SSH and a deploy
+# key from Vault. Deliberate: this repo is already anonymously readable over
+# HTTPS on gitea, so a deploy key would guard nothing while adding a Vault entry
+# and a gitea key to create by hand before anything deploys. TLS still gives
+# integrity and authenticity of the source.
+#
+# If the gitea repos are ever made private, this becomes an SSH sourceRef with
+# an ExternalSecret holding the deploy key — the pattern in
+# kong-catalog-api/dev/.
+apiVersion: source.toolkit.fluxcd.io/v1
+kind: GitRepository
+metadata:
+  name: catalogue-agent
+  namespace: agents
+spec:
+  interval: 5m
+  url: https://gitea.sttlab.eu/stt/classic-models-agent-catalogue.git
+  ref:
+    branch: main