catalog: two tiny services, so the loop can be exercised on a full cluster

The three existing entries are sized like real products: `elasticsearch` small
asks for 1Gi and medium for 4Gi across three replicas. On this cluster that is
a request that never schedules, so provisioning them proves something about the
node and nothing about svcforge.

  podinfo  16Mi/10m  — one small Go binary, no dependencies, no PVC
  nginx    32Mi/10m  — recognisable, still small

Both are addressed as `oci://`, which is load-bearing rather than cosmetic. An
OCI chart is pulled by reference with no `helm repo add` first. The three
existing entries name `bitnamilegacy/<chart>`, a classic repo alias that
nothing in the worker image configures — so as written they cannot resolve at
provision time. OCI is the form that works from a bare container, and it is why
the e2e test already provisions podinfo.

Chart versions were resolved against the real registries before committing
(podinfo 6.7.1, nginx 25.0.14 / app 1.31.3) rather than guessed, since a wrong
version fails only at provision time.

Also updates the CLI ServiceType enum, the catalog test's expected set, and the
service list in the OpenAPI description.

catalog.yaml

@@ -75,3 +75,70 @@ services:
           limits:
             cpu: "2"
             memory: 4Gi
+
+  # --- Small services, for exercising the control plane on a cluster with no room ---------
+  #
+  # The three entries above are real products and size accordingly: one `elasticsearch`
+  # small asks for 1Gi, and a medium asks for 4Gi across three replicas. On a test cluster
+  # that is a request that never schedules, so provisioning them proves nothing about
+  # svcforge and everything about the node.
+  #
+  # These two exist to exercise the actual loop — claim, helm install, CAS to ready, drift,
+  # TTL, deprovision — in seconds and in tens of megabytes.
+  #
+  # Both are addressed as `oci://`, which is not cosmetic: an OCI chart is pulled by
+  # reference with no `helm repo add` first. The entries above name `bitnamilegacy/<chart>`,
+  # a classic repo alias that nothing in the worker image configures, so they cannot
+  # actually resolve at provision time. OCI is the form that works from a bare container.
+
+  podinfo:
+    # A single small Go binary with no dependencies, no PVC and a fast image pull. The e2e
+    # test provisions exactly this for the same reason.
+    chart: oci://ghcr.io/stefanprodan/charts/podinfo
+    chart_version: 6.7.1
+    security: false
+    sizes:
+      small:
+        replicas: 1
+        resources:
+          requests:
+            cpu: 10m
+            memory: 16Mi
+          limits:
+            cpu: 50m
+            memory: 32Mi
+      medium:
+        replicas: 2
+        resources:
+          requests:
+            cpu: 25m
+            memory: 32Mi
+          limits:
+            cpu: 100m
+            memory: 64Mi
+
+  nginx:
+    # A recognisable web server, still small. Useful when the thing being demonstrated needs
+    # to look like a service someone would actually ask for.
+    chart: oci://registry-1.docker.io/bitnamicharts/nginx
+    chart_version: 25.0.14
+    security: false
+    sizes:
+      small:
+        replicas: 1
+        resources:
+          requests:
+            cpu: 10m
+            memory: 32Mi
+          limits:
+            cpu: 100m
+            memory: 64Mi
+      medium:
+        replicas: 2
+        resources:
+          requests:
+            cpu: 25m
+            memory: 64Mi
+          limits:
+            cpu: 200m
+            memory: 128Mi