scansw: remove pre-built armhf binary; fix Pi 5 aarch64 support

[dmz006]

Problem

The repo ships a pre-built 32-bit ARM (armhf) scansw binary:

ELF 32-bit LSB executable, ARM, EABI5
dynamically linked, interpreter /lib/ld-linux-armhf.so.3

On a Raspberry Pi 5 running 64-bit Raspberry Pi OS (aarch64), make sees the binary as already built and skips compilation. The result is an armhf binary that fails at runtime with Exec format error when the GPIO driver tries to exec it — all lamp and switch functionality silently fails. The lamps never light up and the boot-select encoder does nothing.

Root cause

scansw is committed to the repo but not listed in .gitignore. When make runs it checks whether the output file exists, sees scansw, and skips the compile step — even though the existing binary is the wrong architecture.

Fix

This PR:

1. Adds scansw to a .gitignore in the scanswitch/ directory so the binary is never committed again and make always compiles from source.
2. Removes the existing armhf binary from git tracking (git rm --cached).
3. Adds a note to README.md for Pi 5 / 64-bit OS users.

No source code changes. The C code already supports Pi 5's RP1 chip via pinctrl/gpiochip_rp1.c — it just needed to be compiled for the right architecture.

Tested

• Pi 5 + Raspberry Pi OS 64-bit (Bookworm, aarch64)
• rm scansw && make in src/11_pidp_server/scanswitch/ produces an aarch64 binary
• GPIO lamps and boot-select switch confirmed working on Pi 5 with PiDP-11 hat

Related

• Issue Docker / Podman wrapper #15 (Docker/Podman wrapper) — this fix was discovered while building an arm64 Docker image. See that issue for a community-maintained arm64 container image.

Impact on 32-bit users

None. Existing armhf users who have scansw in their working tree won't notice any change — git pull will simply stop tracking the binary and make will rebuild it (correctly, for armhf) the next time it runs.