fix the node manifest and make the example dataflow self-contained

Two problems, both found by the validate job once it could finally run.

categories named `teleop` and `input`, neither of which dora defines. The set is
fixed — sensor, actuator, robot, transform, filter, ml-inference, llm, speech,
communication, recorder, visualization, simulator, debug — and an unknown
variant makes the whole manifest unparseable, so every type annotation in it was
being ignored.

dataflow.yml spanned three repositories through sibling paths, which meant dora
could not resolve the other nodes' manifests and reported their typed outputs as
unannotated. It also could not be validated in CI, which clones one repo. The
house pattern is a self-contained dataflow, and this now follows it: teleop plus
a bench stand-in for the arm and the browser, both from this checkout. The real
three-node wiring moves to README.md, where a consumer would look for it.

The bench answers every service, publishes plausible telemetry, and prints the
velocities it is sent, so the node can be driven from a real gamepad with no
robot in the room. It is not a simulator and must not become one: it never
integrates a velocity or moves a pose.

dataflow.yml

@@ -1,12 +1,13 @@
-# The whole operator stack, and what CI validates.
+# The repo's own example, and what CI validates.
 #
-# Built from checkouts rather than tags, so `dora validate` resolves each node's
-# manifest from its `path:` and checks the wiring against the versions in front
-# of you. The sibling repos are expected next to this one, which is how they are
-# cloned in practice.
+# Self-contained on purpose: teleop plus a bench stand-in for the arm and the
+# browser, both built from this checkout, so `dora validate` resolves every
+# manifest from `path:` and CI needs no gamepad, no robot and no sibling clones.
 #
-# Three nodes, one loop: the bridge carries the browser, this node decides who
-# drives, and the arm node moves the arm and reports back.
+# This is **not** the real stack. The bench answers services and publishes
+# telemetry but never moves anything — it exists so the node can be driven from
+# a real gamepad with no arm in the room. README.md carries the three-node
+# wiring a consumer actually uses.
 
 strict_types: true
 
@@ -16,13 +17,11 @@ nodes:
     build: pip install .
     inputs:
       tick: dora/timer/millis/50
-      ui_command: ws-transceiver/data_out
-      clients: ws-transceiver/clients
-      response: ulite6/response
-      motion_state: ulite6/motion_state
-      robot_state: ulite6/robot_state
-      tcp_pose: ulite6/tcp_pose
-      joint_pose: ulite6/joint_pose
+      clients: bench/clients
+      response: bench/response
+      robot_state: bench/robot_state
+      tcp_pose: bench/tcp_pose
+      joint_pose: bench/joint_pose
     outputs:
       - jog
       - request
@@ -31,35 +30,16 @@ nodes:
       SPEED_MM_S: "60"
       SPEED_DEG_S: "30"
 
-  - id: ws-transceiver
-    path: ../dora-websocket-transceiver
-    build: pip install .
+  - id: bench
+    path: examples/bench.py
     inputs:
-      data_in: teleop/ui_state
-    outputs:
-      - data_out
-      - clients
-    env:
-      WS_PORT: "9000"
-      STATIC_DIR: "../dora-teleop/web"
-      HTTP_PORT: "9010"
-
-  - id: ulite6
-    path: ../dora-ulite6
-    build: pip install .
-    inputs:
-      tick: dora/timer/millis/100
-      request: teleop/request
+      tick: dora/timer/millis/200
       jog: teleop/jog
+      request: teleop/request
+      ui_state: teleop/ui_state
     outputs:
       - response
-      - motion_state
-      - joint_pose
-      - tcp_pose
       - robot_state
-    env:
-      ROBOT_IP: "192.168.1.192"
-      TOOL_TYPE: "vacuum"
-      # Nothing moves because the node started. An operator asks for the first
-      # motion, which is the whole point of a teleop stack.
-      INIT_MODE: "none"
+      - tcp_pose
+      - joint_pose
+      - clients