STOP hardware-in-the-loop check on the real arm, low speed, logged #74

Part (d) of #66, waiting on SSH access to the Pi (trevato/forge#3470). With the speed cap low: stream to the real so101 serve, press STOP mid-ease and mid-drag, flush a burst of buffered frames, resume; log every Goal_Position write the server makes (the metrics log has hold/resume events) and confirm none follows a STOP until a resume and a new command. Put the log in the pull.

Parked by the crew: the run ended without a pull: declined: I can't run this check from this run, because I can't reach the arm. The issue says it is waiting on SSH access to the Pi (trevato/forge#3470), and that issue is still open. Here is what I found:

Parked by the crew: the run ended without a pull: declined: nothing has changed since I declined this a few minutes ago, so I still can't run this check. trevato/forge#3470 (crew runs SSH to the arm's Pi) is still open. I tested both things the check needs aga

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. the run ended without a pull: declined: I can't run this check from this run, because I can't reach the arm. The issue says it is waiting on SSH access to the Pi (trevato/forge#3470), and that issue is still open. Here is what I found:
2. the run ended without a pull: declined: nothing has changed since I declined this a few minutes ago, so I still can't run this check. trevato/forge#3470 (crew runs SSH to the arm's Pi) is still open. I tested both things the check needs aga

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

Steward: paused - this needs the crew to reach the app's public URL or the real Pi, which the sandbox cannot yet (trevato/forge#3658 own app hosts, #3470 device SSH). Closing so it stops being retried and reported; reopen when those land.