fix: ignore Input's status queries after a screen unlock

[timwata]

What

After closing and reopening the MacBook's lid, the panel showed "Also driving this pad: input — colours may fight." until Recheck was pressed.

Why

Work Louder's Input app listens for Electron's unlock-screen, drops and reopens every device, and a second after reconnecting asks the pad for device.status (falling back to sys.version) — read from its bundle (app.asar: disconnectAllDevices(), onDeviceConnected). Both replies are objects, so the null-only filter from #21 let them through. Input was a known quiet holder, the fallback laid the reply at it, and the warning stayed for as long as Input runs.

Change

• BridgeController.isAboutTheLighting(result:error:): a foreign reply counts only when it is an error or a dictionary with an ok key — what the lighting calls and fs.write answer. Queries (sys.version, device.status, fs.list, fs.read) and host.focused_app no longer count; errors still do.
• Tests: the unlock/reconnect sequence (Input leaving and returning in the registry, then its status replies), and which of the emulator's answers count. Mutation-checked: the old null-only filter fails both (and blames "Input"); ignoring errors fails the error tests.
• Docs: README.md, docs/hacking.md, CLAUDE.md, design/pad-contention.md Notes.

Behaviour change: the Inspector only sends sys.version and device.status when it connects, so opening it no longer raises the warning; sending a colour from it does.

Checks

• swift build -c release (zero warnings) and env -u HERDR_SOCKET_PATH swift test green.
• User checks on hardware (done by the user): with Input running, lid close/open and unlock → no warning; a colour sent from the Inspector → named warning.

🤖 Generated with Claude Code