docs(questions): v5 — v4 answers recorded (relay hw, probe cleared, HA whitelist); PR approver questions [#345]

Founder answered Q1-Q3 2026-09-02; new Q4/Q5 ask for named PR
approvers and pfv-bms protection scope.

https://projects.knownelement.com/issues/345

questions-v4.md

@@ -1,28 +0,0 @@
-# Questions — v4 (current round)
-
-Round v3 closed 2026-09-02 with no open repo-local questions.
-This round opens 2026-09-02 for the badge doorman modernization.
-
-## Badge doorman modernization (#345 / #355 / #356)
-
-**Q1. Door actuator path?** The 2018 `doorman.pl` fired a `usbrelay`
-(device 3X9XI_1) door strike from the reader host. Is that still the
-hardware on the server-room door, or does the new e-lock (Fri 09-04
-onsite batch) take over the strike? If e-lock: make/protocol
-(Zigbee / Z-Wave / HomeKit / wired)? This decides whether HA unlocks
-natively or the pfvsvrpi listener drives the relay on HA's behalf.
-**A:**
-
-**Q2. Reader model + badge format?** Old reader was a keyboard-emulating
-USB RFID reader (usb-13ba "Barcode_Reader"), 10-digit raw-decimal IDs.
-From the box with a reader at fingertips (ultix-field is live in San
-Antonio): paste `lsusb` and `ls -l /dev/input/by-id/` output — and if
-convenient, one badge scan captured with `evtest`.
-**A:**
-
-**Q3. Badge whitelist home?** Proposal: the whitelist lives in HA
-(pfv-bms package: badge_id → identity), replacing the defunct
-doors.pfv.turnsys.net portal and the hardcoded backdoor list. The two
-legacy 2018 badge IDs (Charles NW / Josef C) get re-enrolled through the
-new path, never hardcoded again. Confirm?
-**A:**