test(interop): daemon end-to-end vs secsgem-py reference host

daemon_interop.py drives a running secs_gemd through BOTH faces at once: a
gRPC tool client and a secsgem-py active host. Proves the gRPC<->HSMS bridge
against a reference GEM implementation, not just in-process:

  - gRPC GetControlState agrees with the HSMS-driven control state
  - gRPC SetVariables(ChamberPressure=2.5) + FireEvent(ProcessStarted) makes
    the host receive S6F11 CEID 300 carrying 2.5 (value flowed gRPC -> engine
    -> HSMS -> host)
  - unknown variable/event names rejected at the gRPC edge

Mirrors the existing host_vs_cpp_server.py pattern. New 'gemd' compose service
(HSMS :5000 + gRPC :50051); interop image gains grpcio/grpcio-tools (proto
stubs generated at runtime, flat to avoid the secsgem package-name clash).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docker-compose.yml

@@ -55,6 +55,24 @@ services:
     command: ["/app/build/secs_client", "--host", "server", "--port", "5000", "--device", "0"]
     networks: [secs]
 
+  # The gRPC daemon: passive HSMS equipment on :5000 plus the gRPC tool API
+  # on :50051. Used by interop/daemon_interop.py (a gRPC tool + a secsgem-py
+  # host both drive it) to prove the gRPC<->HSMS bridge against a real host.
+  gemd:
+    <<: *base
+    depends_on:
+      builder:
+        condition: service_completed_successfully
+    command:
+      - /app/build/secs_gemd
+      - --port
+      - "5000"
+      - --grpc
+      - "0.0.0.0:50051"
+      - --config-dir
+      - /app/data
+    networks: [secs]
+
   # Python container preloaded with secsgem-py 0.3.0 for cross-validation
   # of our C++ HSMS/SECS-II/GEM implementation against the reference library.
   interop: