Expand Glitch operations hub, cabinet authoring, deployment, and RFID support

Operator hub
- Introduce Escape Gallery branding and Glitch: the Dark Machine room views
- Add cabinet illustrations, Pac-Man marquee/gameplay artwork, and waiting states
- Add device feedback panels with RFID readings, input/output states, and stale status
- Add logged operator hardware interventions with request deduplication

Room and cabinet authoring
- Add a visual custom-PCB connection editor with per-cabinet device inventory
- Support device IDs, bindings, wiring notes, input polarity, and validation
- Add physical-room label/dimension toggles and editable doorway annotations
- Preserve doorway changes through undo, save, and revert
- Expand cabinet profiles, room layout, and Glitch scenario resources

Scenarios and gameplay
- Add per-assignment game configuration and runtime feature validation
- Add timed test wins and Frogger individual-home objectives
- Add the three-cabinet timed/score/Frogger test scenario
- Add Cabinet 1 Pac-Man RFID credits, credit sound, and CREDIT 0/1 display
- Require physical Start after an accepted scan and prevent duplicate credits

Pi hardware and deployment
- Add GPIO feedback sampling and a separate multiplexed RFID helper
- Validate reader pin ownership and input/output conflicts
- Add SSH cabinet startup and Pi desktop-session service support
- Add master packaging, site setup, SSH enrollment, and staged cabinet releases
- Verify deployment manifests and support explicit activation/status/log commands

Documentation and verification
- Consolidate the root README around the current architecture and setup workflow
- Add the complete master/Pi/RFID export and deployment walkthrough
- Document network isolation, credentials, card identification, and rollback
- Add PCB, room-editor, feedback, credit, deployment, and controller tests
- Isolate protocol tests from designer-edited cabinet configurations

Known limitations
- RFID helper compilation and physical Pi commissioning remain unverified
- Fleet provisioning does not yet configure RFID-only installations completely
- Broader Pac-Man tests retain a ghost-capture assertion failure
- Staged exports must be rebuilt and checked before deploying runtime 2.3

tools/pi_gpio/README.md

@@ -40,7 +40,7 @@ If this fails, fix the reported GPIO permissions/package error or check the resi
 
 ## 4. Start the GPIO helper
 
-Copy **pi_gpio_bridge.py** from this folder alongside the exported game on the Pi. It is a separate Python program, not an embedded Godot resource. Keep it running in a terminal:
+Copy **pi_gpio_bridge.py** and **device_feedback.py** from this folder alongside the exported game on the Pi. It is a separate Python program, not an embedded Godot resource. Keep it running in a terminal:
 
 ```sh
 GPIOZERO_PIN_FACTORY=lgpio python3 pi_gpio_bridge.py --controller cabinet_01_gpio --pins 17
@@ -81,3 +81,38 @@ Keep the helper running while restarting games with Escape. For unattended boot,
 Bridge tests cover pulse timing/retriggering, active-low configuration, digital off, watchdog expiry, rejected pins/controllers, and shutdown. The Godot integration test sends a real HTTP request from a Pac-Man win to a test bridge with fake GPIO devices. Physical voltage and your wiring must still be verified on the Pi.
 
 References: [GPIO Zero installation](https://gpiozero.readthedocs.io/en/stable/installing.html), [output device API](https://gpiozero.readthedocs.io/en/stable/api_output.html).
+
+
+## PCB live feedback
+
+This optional integration requires the updated controller, launcher, bridge plus `device_feedback.py`, and a new Godot cabinet export (`arcade-cabinet-2.2`). No installation is performed by editing the PCB diagram. Odin remains separate.
+
+1. Save each cabinet's PCB connections in the Godot editor. Give every device a unique ID. For buttons/sensors, check **Input pull-up** when the switch activates by connecting the signal to GND; verify the actual circuit first.
+2. Export the catalog from the project root:
+   ```sh
+   godot --headless --path . --script res://tools/room_controller/export_catalog.gd
+   ```
+3. Extract that cabinet's inventory (the destination must not already exist):
+   ```sh
+   python3 tools/pi_gpio/device_feedback.py --catalog tools/room_controller/catalog.json --cabinet cabinet_01 --output devices.json
+   ```
+4. Copy the inventory and updated software to that cabinet Pi. For RFID, enable SPI using Raspberry Pi configuration and build the separate helper on a Pi with a Rust toolchain:
+   ```sh
+   cargo build --release --manifest-path tools/pi_gpio/rfid_helper/Cargo.toml
+   ```
+   The binary is `tools/pi_gpio/rfid_helper/target/release/arcade-rfid`. The source follows Odin's MFRC522 library and selector sequence, but this new helper has **not yet been compiled or tested on the tester Pi**. It requires access to GPIO and SPI. Do not run Odin's reader service simultaneously.
+5. Add these optional settings to the existing launcher's `[gpio]` section, with paths relative to the launcher INI (or absolute paths):
+   ```ini
+   devices = /home/YOUR_USER/arcade/devices.json
+   rfid_helper = /home/YOUR_USER/arcade/tools/pi_gpio/rfid_helper/target/release/arcade-rfid
+   pins =
+   ```
+   An empty `pins` list is valid for input/RFID-only testing. If outputs are configured, list only their actual BCM pins and keep the corresponding HardwareActions aligned. Omit `rfid_helper` if no RFID readers are configured. Keep the existing real-GPIO launcher setting enabled.
+
+**Pin ownership:** RFID uses BCM17/27/22 for selection, BCM20 for reset, and SPI0 (BCM8/9/10/11). These cannot also be general outputs. The earlier standalone LED example on BCM17 and start-light example on BCM20 must not be used with this RFID setup. Inputs cannot also be in the output allowlist. The bridge rejects these conflicts before starting.
+
+The operator's cabinet detail and Hardware views display per-device readings. Activity records changes. Disconnected or old samples become stale. J1/J2 are scanned as selector slots 0/1; additional configured readers are scanned in sequence. RFID values currently use Odin's 32-bit UID representation and are not a promise of a complete UID for every card type. A failed tag read is shown as absent **or unreadable**, rather than proof that a card was removed.
+
+Outputs report the GPIO device's logical electrical state after initialization, not proof that a lock or motor moved. Physical confirmation needs a separate sensor. I2C/Other devices are not sampled yet. Feedback is monitoring only; automatic scenario rules for these events are not enabled by this change.
+
+Start with a button and the two readers, then test an appropriately driven output. Confirm real readings and stale/disconnected behavior on the Pi before relying on this for room operation. Windows tests use fake devices; no physical pins were exercised during development.