add a probe that shows what the gamepad is doing

The axis and button indices in mapping.py are SDL's documented layout rather
than an observed one, and until now the only way to find a pad that numbers
things differently was to watch a real arm move the wrong way.

`dora-teleop-probe` prints the raw axes, the buttons it sees and the velocity
that would be sent, live, with no dataflow and no arm — it cannot move anything.
It goes through the same Gamepad and velocity() the node runs, so what it prints
is what the arm would get; that is the whole reason it is worth having, and the
reason it must not grow its own copy of the mapping.

Every axis is listed, including ones the layout does not use, because an axis
marked unused that moves when a stick is pushed is exactly the finding this is
for. The centred bar makes a worn stick that does not return to zero obvious.

AGENTS.md

@@ -38,7 +38,7 @@ expected next to this one.
 ## Test
 
 ```bash
-uv run pytest      # 66 tests, no gamepad, arm, browser or daemon needed
+uv run pytest      # 76 tests, no gamepad, arm, browser or daemon needed
 uv run ruff check .
 uv run ruff format --check .
 ```
@@ -77,6 +77,12 @@ a source goes away**.
   first time somebody picks up the pad. Errors name the variable.
 - **`dora_teleop/log.py`** — Timestamped stderr logging. stderr because dora reads a
   dynamic node's stdout.
+- **`dora_teleop/probe.py`** — `dora-teleop-probe`: shows the raw axes, the buttons and the
+  velocity that would be sent, with no dataflow and no arm. It exists because the indices
+  in `mapping.py` are SDL's documented layout rather than an observed one, and a pad that
+  disagrees is otherwise found by watching a real arm move the wrong way. It goes through
+  the same `Gamepad` and `velocity()` the node runs, so what it prints is what the arm
+  would get — keep it that way, or it stops being evidence.
 
 ## Rules that are not negotiable