Add puppet passthrough example for dashboard robot control

[SaintSampo]

What

Adds XRPExamples/puppet_passthrough.py: a program that hands direct control of the
robot's actuators to the XRPWeb dashboard over the puppet protocol (XPP). The dashboard's
Robot Control widget starts it exactly like the Run button starts any user program, so it
requires zero changes to puppet.py, main.py, or the normal edit/upload workflow —
it's just an example file that ships with the library.

How it works

On startup the program probes which actuators the board actually has (the get_default_*
helpers return Exception objects for missing ports — e.g. servo 3/4 and motor 4 on some
boards) and defines a puppet variable per available channel. The auto-sent VAR_DEFs
double as the handshake: the browser learns the channel list and enables matching
controls, so boards with fewer ports simply show fewer controls.

Variable	Dir	Meaning
$servo.1–$servo.4	in	servo angle, degrees
$motor.left/right/3/4	in	motor effort, −1…1
$led	in	onboard LED on/off
$drivetrain.straight / $drivetrain.turn	in	blocking motion commands (cm / degrees; nonzero triggers)
$drivetrain.straight.effort / .turn.effort	in	max-effort parameters for the above (persistent settings)
$drivetrain.busy	out	pushed true/false around a blocking motion
$button	out	user button state, pushed on change via pin edge IRQ (no polling)
$board.type	out	0 = Beta XRP, 1 = XRP, 2 = NanoXRP
$puppet.keepalive	in	browser liveness ticker (value ignored; arrival matters)

A 50 Hz main loop applies values on change only, so starting the passthrough never
snaps servos or spins motors.

Safety / robustness notes

• Motor watchdog — if no packet arrives for 2 s (tab closed, cable pulled, BLE drop),
  motors stop, and the stale effort is cleared from the puppet registry so a reconnecting
  browser can't resurrect it. Servos and LED are deliberately left as-is.
• Blocking motions — straight()/turn() block the loop, so $drivetrain.busy is
  the browser's only feedback during a run. Every motion gets an effort-scaled timeout
  (a jammed or lifted robot can't freeze the program forever), commands that arrive
  mid-motion are discarded, and cleanup runs in a finally so IDE-Stop mid-motion still
  reports not-busy. Motions end with motors stopped, and the registry is zeroed to match
  so pre-motion slider values can't silently re-apply.
• Button by interrupt — the edge IRQ handler only sets a flag (no allocation, no
  BLE/USB writes from IRQ context); the main loop reads the pin and pushes the update,
  which also coalesces contact bounce.
• Stopping — works like any program: the puppet protocol passes Ctrl-C through even
  while it owns the USB stream, and the run harness's resetbot frees the actuators.