Lunar Porter takes any controller, not the first one

A controller does not always arrive on pad nought. The front end hands out
the numbers the host gave it, so a game that reads only the first one
works on the machine it was written on and silently does nothing on the
next - which is the shape of "the pad is detected, Pad shows it, and the
game ignores it".

Four reads and three ORs. One person flies this and which socket they
plugged into is not a thing they should have to know. Presence is any of
the four bits rather than the low one, for the same reason.

The manifest's pad column takes several fixtures now, comma separated, and
they fill the pads in turn. So cosmosLanderPadOne holds nothing on pad
nought and flies the whole landing on pad one - a test that fails on the
version of this program that shipped an hour ago.

Also confirmed while looking: raylib 6 does refresh which gamepads are
ready every frame in PollInputEvents, so a hot-plugged pad should be seen.
Whatever is stopping that is above us and worth a separate look.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW

SplitBit Test Manual.md

@@ -101,7 +101,7 @@ from `make`, not from here.
 ### 1. Recorded output
 
 `Tests/run.sh` assembles each program named in `Tests/manifest`, runs it, and compares
-everything it printed against a file in `Tests/expected`. 210 tests, of which 148 run, 35
+everything it printed against a file in `Tests/expected`. 211 tests, of which 149 run, 35
 only assemble, 16 are expected to fail to assemble, and 11 boot from ROM with no image
 given at all.
 
@@ -405,7 +405,9 @@ test the window: Voyager's own key queue is still out of reach, and so is anythi
 presenting frames. It tests the console, which is where the logic is.
 
 **pad** names a file in `Tests/input` to be held on a controller, one byte a frame, each
-byte the buttons held during it. It exists for the same reason as **keys** and matters more:
+byte the buttons held during it. **Several, comma separated**, fill the pads in turn - so a
+first fixture holding nothing and a second that does something puts the flying on pad one,
+which is how a game that reads only the first controller gets caught. It exists for the same reason as **keys** and matters more:
 a pad reports what is *held*, and a suite has no hands.
 
 **A byte a frame, not a byte a read.** A pad is a level, so a game that asks twice in one